Re^5: Random quotes in the top left corner

[tilly]

I still disagree. In real world cases tightly integrated designs have often been viable a decade or more before modularized designs came to market. This is not a question of building a throw-away (though your solution will be superceded once raw performance isn't as important as, say, customizability), it is a question of being able to create the right product at the right time.

Let's look at an analogous situation comparing languages rather than development techniques. Suppose that Perl is 10x slower than C. But it is clearly preferable to accomplish a speific task in Perl. Then from Moore's law we can project that it will be feasible to do that task in C about 5 years before it is feasible to do it in Perl. The C solution will be doomed, eventually someone will do it in Perl and the Perl solution will be more flexible and customizable and will win. However the C solution will not be a throw-away, it will be able to meet a need before the Perl one could. Furthermore with the 5 year headstart on development, the C project could easily remain better than Perl for several years after CPUs become good enough for the Perl solution. So for perhaps a decade, despite the obvious reasons to prefer Perl, everyone will use a solution built in C.

The same thing happens with modularization. For instance in the mini-computer market, the first successful operating systems (Apollo, VMS, etc) were tightly integrated with the hardware. Eventually they all lost to Unix, which was significantly more modular in design. But they were not throw-away solutions, and for many years was what everyone used.

[adrianh]

I still disagree. In real world cases tightly integrated designs have often been viable a decade or more before modularized designs came to market.

You seem to be implying (and please correct me if I'm wrong ;-) that loosely coupled systems are necessarily slower to market and/or perform significantly worse than tightly coupled solutions?

If so, I'm not entirely convinced. When I see tightly coupled software being produced it's normally a combination of one or more of:

• Developers not having the necessary knowledge of ways to create software in a loosely coupled manner (e.g. not knowing about techniques like dependency injection.)
• Not having appropriate tools to make the development of loosely coupled software simple (e.g. a language like Perl or Java offers more features that help with loose coupling than a language like C or COBOL.)
• Not having experience of software development practices that encourage loosely coupled software (e.g. using TDD.)

Sure - there are some instances where a tightly coupled system has been deliberately chosen due to some constraint - but they seem rare in my experience. More often they're done first because that's the only way the developers know how to create software.

[tilly]

I am not implying that.

I am implying that maintaining loose coupling necessarily keeps you from being able to find certain kinds of optimizations, and that means that the top possible performance (tight memory, etc) can be hit by a tightly integrated application. If performance is a significant constraint (mini computers in the 70's, GUI interfaces on PC hardware in the 80's, PDAs in the 90s) then tightly coupled systems may be viable several years before loosely coupled ones are.

(As a practical matter, most attempts to write a tightly coupled system will result in something slower than a loosely coupled system could have been. This is certainly a strategy that one would only try with very good reason.)

This applies to a small minority of software, and applies to virtually none in the Perl world. Places where I might expect to see this happen today include extremely high-volume servers (eg Google), very constrained systems (eg many embedded projects), and computationally intensive products (some games). None of those are good candidates for Perl because Perl is relatively big and slow.

[adrianh]

I am not implying that.

My bad. Then we agree :-)

As a practical matter, most attempts to write a tightly coupled system will result in something slower than a loosely coupled system could have been. This is certainly a strategy that one would only try with very good reason.

Yup. I think the point many people miss is that loosely coupled code/design doesn't necessarily lead to a hideously inefficient implementation. Even a naive loosely coupled implementation is not necessarily inefficient. Take into account the fact that compilers have got jolly clever over the years and picking a tightly coupled solution without a very good reason is foolish in the extreme.

[apotheon]

I have a couple of problems with your explanation.

First, the performance and rapid development gains in tight coupling typically aren't as significant (and, in the case of rapid development, perhaps aren't even typically extant) as they are for simply choosing the right tool (language) for the job. The analogy you provide doesn't strike me as being particularly viable.

Second, the importance of incremental performance gains from tight coupling decreases over time as system performance capability increases. The reason that UNIX was able to overcome less modular designs didn't have so much to do with the fact that less modular designs were superseded as the fact that less modular designs were no longer a simple necessity of hardware restrictions. I tend to think that as system performance capability increases, we'll see further evolution toward modularization, and what we think of as loose coupling today may be classed as tight coupling in a few years.

Older, less modular OS designs didn't develop so much because they provided a simpler path toward development as because A) greater modularity in design hadn't really been experimented with very much yet and B) more modular design simply wouldn't run on the comparatively limited hardware available at the time.

[tilly]

I find it ironic that you have problems with my explanation, and then proceed to indicate that you got the main point.

Your reason B for less modular OS designs was exactly my point. Less modular designs were feasible on the hardware before a more modular design would be. Once more modular designs became feasible, it was only a question of time until one emerged as a standard and then won due to advantages in cost, configurability, and maintainability. But there was a window where non-modular solutions made sense.

[apotheon]

I think I may not have been clear enough in what I was saying about your point.

Specifically, it seems likely to me that the necessity of tight coupling in new OS development is largely a thing of the past. Advances in hardware have created a greater value for developer resources and a lesser value for system resources, across the board, and that this reduces the value of tight coupling in new system development to the point where it is negligible (except perhaps in concept prototyping).

Yes, there was a time when non-modular solutions made more sense, but they don't really make any sense any longer, for the most part — often even in experimental development, contrary to what I understood of your earlier statements.