Random Thought For The Day
At the ACCU conference a week or so back, Steve Alexander mentioned that the constituent parts of large Python projects he'd worked on were more loosely coupled than those of similarly sized Java projects.
I wonder if this is in part because of the prominence of unit testing in the Python world.
If you're trying to write a unit test for some object that requires you set up six billion other objects before you can create an instance of the class being tested (a) you don't have a unit test any more and (b) it's just really really annoying. It always helps when doing the wrong thing grates.
I doubt this counts as a particularly profound thought, but I've just now had it strike me. I guess this is also an XP-ish thing: when you come across something that smells bad like the tight coupling I've just been removing, do something about it. Like, now.
Another tangent to this is when you're doing test driven development (I don't feel I can capitalize that phrase in the context of what I've been doing for this particular personal hack) you really have to structure your program in a way that supports this methodology. I'm not sure people always realize this.
To pick two methodologies that in some sense are opposite extremes, consider the arguments that crop up from time to time between the static typing crowd and the unit testing crowd. The static typing crowd are used to structuring their programs in a way that maximizes the advantage of their methodology, i.e. crafting types in such a way that if your program compiles it has a damn good chance of doing what you want. The unit testers are experts at separating their problems into components that can be tested individually and writing thorough tests. I suspect that some of the reasons for the flamewars is a failure to appreciate the other "side's" practices.
(Hopefully you'll have noticed an assumption above that "static typing" means ML or Haskell or something like that. C coders just lose. Java I don't know much about but probably loses too. In C++ it's probably possible not to lose, but oh my, it hurts.)
As to which "side" is better, well, I'm not going to attempt an answer to that question :-) One thing to consider, though, is the side benefits of a given methodology such as the unit testing driving loose coupling. There are probably side benefits to the powerful static type system approach, too. I will notice that for sub-genius programmers, the unit test approach is probably just plain easier.
Of course, there no reason static typing and unit testing are mutually exclusive. Though, it seems to me that a unit test framework for ML (say) would have to include tests that 'merely' assert that some piece of code does or does not compile -- unit testing the type system, in other words. Hmm, the advantages of setting things down in prose: that last thought had definitely not occurred to me when I started this post... I wonder if any work has been done in this direction.
Oh yes, the hack I've been working on: a PowerPC assembler in pure Python :-)
This has its own special fun in that a failing test is more likely to show up as a core dump than as a traceback...