Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!cmcl2!beta!hc!ames!orville.nas.nasa.gov!fouts From: fouts@orville.nas.nasa.gov (Marty Fouts) Newsgroups: comp.lang.misc,comp.lang.smalltalk,comp.lang.c++ Subject: software ICs (was Re: C++ vs Objective-C) Message-ID: <3179@ames.arpa> Date: Wed, 21-Oct-87 14:29:32 EDT Article-I.D.: ames.3179 Posted: Wed Oct 21 14:29:32 1987 Date-Received: Sat, 24-Oct-87 05:27:32 EDT References: <3405@ece-csc.UUCP> <638@its63b.ed.ac.uk> <1811@watcgl.waterloo.edu> <1549@pdn.UUCP> <1661@ppi.UUCP> Sender: usenet@ames.arpa Reply-To: fouts@orville.nas.nasa.gov.UUCP (Marty Fouts) Organization: NASA Ames Research Center, Mountain View, CA Lines: 59 Xref: mnetor comp.lang.misc:763 comp.lang.smalltalk:369 comp.lang.c++:530 In article <1661@ppi.UUCP> cox@ppi.UUCP (Brad Cox) writes: >. . . But the improvement has always turned out to >be arithmetic in impact. The geometric improvements needed to bring our >productivity in line with that of hardware engineers will not result from >better programming languages, but by focusing our attention outside the >language. For example, by learning to program by producing and reusing >components from large libraries of pre-tested Software-ICs. Yes, these >libraries are hard to build, and expensive. But each well-tested, >well-documented library component provides a geometrical improvement to the >productivity of each of its users, and the improvement is open-ended, unlike >the productivity enhancement of features that are hardwired into a new >programming language. I have three problems with this comment. The one that bothers me the most is the standard marketing ploy of renaming something from its original lackluster name (library routine) to something that sounds exciting, like "Software-IC". Libraries have been around at least as long as programming languages; and have contributed their share to the productivity improvement, but they aren't the glorious path to geometric improvement, or we would have been seeing geometric improvements over the decades. The second problem I have is the analogy which isn't stated here, but is frequently drawn between "Software-IC" and hardware IC. If you follow the component industry at all, you know that the age of TTL 7000 series ICs has all but ended and almost all serious design now is being done with semicustom or custom components. You also know that hardware designers have long bemoaned their lack of productivity, although they refer to it as "design turn-around time", and they haven't been seeing geometric improvements either. Finally, you will realize that the use of off the shelf components has alternated with the use of special purpose design, going back at least as far as the early sixties when the first published circuit books came out. The third problem I have is with the loose claims of 'geometric' as apposed to 'linear' improvements in productivity. I've been reading about programmer productivity for a long time, since Marvin Minsky first claimed that advances in programming languages would do away with the need for programmers within a decade (about thirty years ago) through James Martin's claims to the same effect ten years ago until now. Nobody even knows what programmer productivity is, yet alone at what kind of rates it has been improving at over the last three decades. Further, various kinds of programming have received differing amounts of attention, and ease of accomplishing tasks in some fields has improved greatly compared to others; for instance, using 4GL query languages like SQL, it is now possible to interactively ask for data in a few seconds which used to require hours of programming plus days of backlog waiting for a programer to become available to accomplish. All in all, many things are important in the improvements that have been achieved and none of them alone are going to give the ultimate performance improvement. Careful implementation of languages for maximum expressiveness has improved productivity, as has understanding the way programs should be laid out to aid understanding; but so have faster machines, interactive operating systems, and decent debuggers. It all needs to be worked on, and none of it is going to give us magic productivity enhancements.