bnfb@geocub.greco-prog.fr (Freeman Benson) (07/06/90)
Software is not hardware---the chip/board analogy only goes so far. But why? Mr. Stroustrup pointed out one reason: striving for the best. A similar reason is that the problem is software DESIGN, not manufacturing. Design is still hard, software or hardware, because it is a mental activity. Hardware companies where I have worked took a long time to design their products, just as the software companies took a long time to write their software. Sure, some designs are well known, but then so are some programs: the database 4GLs come to mind. They key is that, with or without object-oriented languages, with or without code libraries, with or without tools, the problem of design is hard. Yes, certain tools help, but only for well-understood problems---in other words, making clones is easy. But we knew that. Bjorn N. Freeman-Benson
rick@tetrauk.UUCP (Rick Jones) (07/09/90)
In article <197@geocub.greco-prog.fr> bnfb@geocub.greco-prog.fr (Freeman Benson) writes: >Software is not hardware---the chip/board analogy only goes so far. >But why? Mr. Stroustrup pointed out one reason: striving for the best. >A similar reason is that the problem is software DESIGN, not manufacturing. >Design is still hard, software or hardware, because it is a mental >activity. Hardware companies where I have worked took a long time to >design their products, just as the software companies took a long time >to write their software. Sure, some designs are well known, but then so >are some programs: the database 4GLs come to mind. They key is that, >with or without object-oriented languages, with or without code libraries, >with or without tools, the problem of design is hard. Yes, certain tools help, >but only for well-understood problems---in other words, making clones is easy. >But we knew that. > >Bjorn N. Freeman-Benson I agree entirely - software is all about design. Even programming, whether or not you are using an OOPL, constitutes generating a detailed DESIGN. The idea that OO methods allow a programmer to "construct" software by fitting together "components" just pushes the hardware analogy too far until it doesn't really fit. Software re-use is about re-using the design specification for a component - the component is the _object_ which only appears when the program executes; the design specification is the program, written as a class in an OOPL. Re-use by inheritance in involves creating a new design based on an existing one; this is distinctly different from adapting an existing component to a new purpose. Thinking too much in terms of the hardware analogy can lead to misconception and confusion about what the software task is really all about. I could go on at length but I don't have the time (net bandwdith wins this time). But it's an important issue when considering what a programming language is supposed to be. -- Rick Jones You gotta stand for something Tetra Ltd. Maidenhead, Berks Or you'll fall for anything rick@tetrauk.uucp (...!ukc!tetrauk.uucp!rick) - John Cougar Mellencamp