scotth@boulder.Colorado.EDU (Scott Henninger) (09/23/89)
|From: mfci!oglesby@uunet.UU.NET (Jose Oglesby) | | Scott Henninger writes: |> I characterize it as a monkey climbing a palm tree to reach the moon. |> He sees he is making progress and begins to make wild claims. |> Unfortunately, he soon reaches a dead end. I claim the dead end in |> software reuse is cognitive overload. It will take thousands or |> millions of components to make a truly useable software reuse |> environment. There is no way that a human can keep track of what is |> available at that kind of scale. | |This is a nice metaphor but I think you spoiled it with your own |wild claim. There is significant difference between thousands and |millions of components. You did not make a good case for your |estimate. As for keeping track of information on that scale, |libraries seem to do a good job of it. Yes, there is a significant difference between thousands and millions of components. This is one of the points I have been making all along. My claim that it may take millions of components comes from my assertion (previously posted) that the scope of software is potentially infinite. Creating domain-dependent design environments can help scale that number down to more reasonable levels, but the numbers are still large, much larger than what we have experienced for hardware or mechanical devices. Remember, hardware instantiates a physical machine, software instantiates a conceptual machine. Just ask any Lawyer how many concepts exist in their domain, which is primarily conceptual. I would claim that the library approach is necessary but not sufficient. The work of Ruben Prieto-Diaz is a good first approximation at solving the problem for software reuse. There are some caveats though: 1) When you access a library information retrieval system, you usually have an author or a title in mind - you only have to find where it is stored. In the rare case where you don't really know what you are looking for, the system usually fails you. 2) Library systems do not handle specific cases. If you want to find an algorithm for depth-first search with hill climbing, you are on your own. You have to guess what kind of book it will appear and then do a serial search - see 3). 3) With code, you have a choice; you can code it yourself or look it up. Given that creating a given piece of code takes far less time (its scope is smaller than a book's) than writing a book, this tradeoff does not exist with books. Reuse library access systems must therefore be more efficient than self-creation. Again, I'm not knocking anyone's work. I just want to point out that the problem is far from being solved. -- Scott scotth@boulder.colorado.edu