3 ms·

There's an element to that article that is complaining about the process that Unix took to get to where it stands now. I feel the author needs to skim some boo

There's an element to that article that is complaining about the process that Unix took to get to where it stands now. I feel the author needs to skim some books on evolution to see that there is nothing inherently wrong with this approach. For instance, his example of Unix is not unlike any large organism who, through years of evolution, has many structures that are no longer needed (e.g. appendix) or structures that seem unnecessarily complex (e.g. recurrent laryngeal nerve) when our 20/20 hindsight can design a better solution. I didn't find too much advice in the article, but I wish he had proposed something better. Even life can potentially create a mutant that contains no archaic structures in it, but it will only last if it passes a fitness test. Why doesn't he try rewriting some of the gnarled pieces of Unix code to make it better (like removing the need for autoconf)?

dllthomas 14y ago
> I feel the author needs to skim some books on evolution to see that there is nothing inherently wrong with this approach. This is broken thinking. You encountered, "Process X has attribute A, and this is bad." and you respond with, "No, because Process Y also has attribute A." This is only valid if we are either 1) guaranteed that there is nothing bad about process Y, or 2) considering processes X and Y as alternative options whose merits we are comparing. Dispensing quickly with 2 - we are considering "Cathedral-mode development" vs. "Bazaar-mode development", not "Evolution" vs. "Bazaar-mode development", so this is not applicable. Without further support, option 1 strikes me as confusion of is-ought. It is the case that evolution works this way, so any design process ought to work this way. There is, however, plenty "wrong with" evolution as an approach to producing designs for a given purpose. It is horribly inefficient compared to design, suffers from greater path dependence, doesn't keep notes about systems that may have worked that went extinct for unrelated reasons, etc. The attribute A that you are comparing is in fact one of the things "wrong with" evolution and "wrong with" Bazaar-mode development. (Note, of course, that a problem with evolution in terms of producing optimal designs for our goals is not the same thing as a problem with evolution as an explanation of the world around us.)

dllthomas 14y ago

> I feel the author needs to skim some books on evolution to see that there is nothing inherently wrong with this approach. This is broken thinking. You encountered, "Process X has attribute A, and this is bad." and you respond with, "No, because Process Y also has attribute A." This is only valid if we are either 1) guaranteed that there is nothing bad about process Y, or 2) considering processes X and Y as alternative options whose merits we are comparing. Dispensing quickly with 2 - we are considering "Cathedral-mode development" vs. "Bazaar-mode development", not "Evolution" vs. "Bazaar-mode development", so this is not applicable. Without further support, option 1 strikes me as confusion of is-ought. It is the case that evolution works this way, so any design process ought to work this way. There is, however, plenty "wrong with" evolution as an approach to producing designs for a given purpose. It is horribly inefficient compared to design, suffers from greater path dependence, doesn't keep notes about systems that may have worked that went extinct for unrelated reasons, etc. The attribute A that you are comparing is in fact one of the things "wrong with" evolution and "wrong with" Bazaar-mode development. (Note, of course, that a problem with evolution in terms of producing optimal designs for our goals is not the same thing as a problem with evolution as an explanation of the world around us.)