|XP is just a number|
Loose vs. Tight Couplingby tlm (Prior)
|on May 02, 2005 at 02:50 UTC||Need Help??|
I have been reading with great interest an exchange between tilly on one side and apotheon and adrianh on the other, on the subject of loosely coupled (aka modular) vs. tightly coupled systems. I thought this was too great a topic, and the arguments presented too well made, for it to be buried in an unrelated thread, so I thought I would turn my $0.02 into a root node, to call attention to this topic and to these comment nodes.
My experience agrees with both sides of this argument. I do scientific programming. The programs I and my colleagues write are intended to perform some analysis (number crunching, or simulations, etc.), and ultimately spit out answers. We are constantly pushing the performance envelope, because the person who gets the paper in Science or Nature is the one who was able to push that envelope the hardest to tackle problems that the rest of the field has not being able to tackle.
But scientific programming often also demands modularity and lose coupling, because every set of results prompts new questions that often make the programs that produced the answers obsolete. So we are in a constant tension between making our programs fast enough (which invariably means tight coupling) and modifiable enough (which means loose coupling).
Hence, we end up doing a lot of hybrid Perl+XS+C programming: Perl wrappers for rapid development and user interfaces, and C libraries for the time-critical core routines. And even the Perl stuff is not as modular is it could be, because it would be too slow. I have re-invented many wheels in pure Perl because the beautifully modular, exquisitely object-oriented stuff I could download from CPAN was simply too slow.
I close with the words of the inimitable Linda Richman: discuss.
Well, I guess that's two lies right there: it's only one word, and Linda Richman is famous only because she is eminently imitable... Oh, well. Too tired now to think of a more truthful ending.
the lowliest monk