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
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...