Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options

Re^2: Random quotes in the top left corner

by apotheon (Deacon)
on Apr 30, 2005 at 07:08 UTC ( #452811=note: print w/ replies, xml ) Need Help??

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




- apotheon
CopyWrite Chad Perrin

Comment on Re^2: Random quotes in the top left corner
Re^3: Random quotes in the top left corner
by tilly (Archbishop) on May 01, 2005 at 01:24 UTC





      I don't think I'd say that my "conclusion" was "wrong" so much as that it was incompletely stated. To round it out nicely, I should have made reference to the idea that first, one should create a throw-away.

      I know that the idea of creating a throw-away version first is an oft-cited principle of software design in general, but it applies even moreso to innovations: first, you innovate, then you create something useful. Sure, tightly couple in the throes of creative frenzy if you must, but then recreate your innovation with more modularity. There's a big difference between screwing around with new ideas and writing good code.

      So, yeah, I think that tight coupling has its place in experimenting with new ideas, but that doesn't mean you should be calling something a release version before you've refactored and restructured so that it's more modular.

      But, again, I could well be speaking too vehemently of things I don't understand well enough. Considering our relative levels of experience with Perl code, I'd be inclined to say that, all else being equal, yours is more likely the "right answer" than mine.

      - apotheon
      CopyWrite Chad Perrin

        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.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://452811]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (6)
As of 2014-07-13 15:30 GMT
Find Nodes?
    Voting Booth?

    When choosing user names for websites, I prefer to use:

    Results (250 votes), past polls