in reply to Re^5: Random quotes in the top left corner
in thread Random quotes in the top left corner

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.

print substr("Just another Perl hacker", 0, -2);
- apotheon
CopyWrite Chad Perrin

  • Comment on Re^6: Random quotes in the top left corner

Replies are listed 'Best First'.
Re^7: Random quotes in the top left corner
by tilly (Archbishop) on May 02, 2005 at 01:44 UTC
    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.

      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.

      print substr("Just another Perl hacker", 0, -2);
      - apotheon
      CopyWrite Chad Perrin

        What makes non-modular solutions make more sense is not the time - there are places where they make sense today and will be places 30 years from now - it is the characteristics of current technology and your problem space.

        While it does not make sense today for problems where it did 20 years ago, there are new problems where it arises today, and there will be undreamed of problems where it arises in 20 years.

        Also there is a certain relative nature to the issue. There is never an absolute line that this is loosely coupled and that is not. Rather you can say that one design is more loosely coupled than another. For instance suppose that OO Perl runs at half the speed of procedural Perl (there is a lot of overhead in making method calls), then using OO techniques to modularize has a huge overhead. Is it worth that overhead to be able to get the benefits of OO? That entirely depends on what you are doing, and what the capabilities of modern hardware are. And if OO doesn't make sense for you to use today, it might in 5 years.

        The result is that software 20 years from now will be able to be shockingly inefficient from the present perspective, just as current software is shockingly inefficient from the perspective of computers 20 years ago. But that inefficiency will buy people something, and one of the things that it will buy them is additional looseness of coupling in layers between the programming abstraction and the actual implementation.