Xref: utzoo comp.software-eng:5347 comp.object:3167 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!princeton!pucc!EGNILGES From: EGNILGES@pucc.Princeton.EDU (Ed Nilges) Newsgroups: comp.software-eng,comp.object Subject: Re: How to pay for reusable software Message-ID: <12676@pucc.Princeton.EDU> Date: 14 Apr 91 17:05:18 GMT References: <1991Apr3.231849.13410@m.cs.uiuc.edu> <3318:Apr705:51:2391@kramden.acf.nyu.edu> <1991Apr12.182420.18587@m.cs.uiuc.edu> <291@dumbcat.sf.ca.us> Reply-To: EGNILGES@pucc.Princeton.EDU Organization: Princeton University, NJ Lines: 77 Disclaimer: Author bears full responsibility for contents of this article In article <291@dumbcat.sf.ca.us>, marc@dumbcat.sf.ca.us (Marco S Hyman) writes: >In article <1991Apr12.182420.18587@m.cs.uiuc.edu> johnson@cs.uiuc.EDU (Ralph Johnson) bemoans: > > Is the marketplace for reusable software destined to be small? > >Possibly, Ralph, but not for the reasons you give. I am constantly amazed at >the number of re-implementations of standard library functions I see in C >code. (Especially the number of broken re-implementations of bsearch.) If >today's programmer (excuse me -- software engineer) can not learn what simple >functions exist in today's standard C library how can we expect them to learn >entire inheritance trees from multiple sources in the reusable software world >of tomorrow. Usually re-implementations of existing library functions are the result of ignorance of what's available, but not always. In the past, not all C compilers came with a complete library and you may be looking at code written in an environment lacking bsearch. The best course would be to replace the re-implementation with the Real Thing, but the re-imple- mentation may have features on which the rest of the code depends or worse it may have bugs on which the rest of the code depends. We badly need a "Programmer's Desk Reference." This would be a book and perhaps an accompanying compact disk which would list languages, compilers, tools and (on the model of the Physician's Desk Reference) their interactions and contraindications. However, in the existing world, such a tool is not likely to be made available. This is because although some company can publish such a book, PART of the authoritative nature of the Physician's Desk Reference was the willingness of physicians and the public to accept it as a neutral authority. I claim that any company publishing a Programmer's Desk Reference will be perceived as biased towards some way of developing software even if it does not have a bias. There is a refreshing consensus right now on the value of C as a programming language, but even C is not The Language of the Gods. The proponents of C++ claim that this language is better and I view REXX as the dark horse of the Nineties, and C is genuinely technically inferior to these languages...perhaps also to Modula and to Oberon. The train will be standing at Babel for the foreseeable future. It's popular nowadays to go to industrial history for software paradigms, but ripping paradigms out of historical context is dangerous. The medical profession as we know it today only arose in the 19th century (my own father was a neurosurgeon who studied under a man who studied under the first neurosurgeon, Cushing of Boston.) It arose in a Progressive matrix in which people were able to believe that a man who sold you Science and Truth was doing so out of an altruistic desire to Serve Mankind (the very sexism of my phraseology dates it, doesn't it?) Nowadays, when a person tries to sell us a programming language, we ask what's in it for you? Professor John Conway on our math department here at Princeton claims he's had to prove theorems many times because he FORGETS he proved them before. Perhaps the excellent programmer of the future will be a skilled reinventor of the wheel, able to create libraries from the ground up in the manner of a barn-raising on the frontier. Perhaps she will be assisted by programming languages powerful enough to do this, and the benefit will be that she won't have to worry about reusing someone else's bugs. I am not saying that this will be so and that it is not a good thing to use the library function whenever possible. But skilled programmers are skilled at BOTH reusing code AND creating reusable libraries: not just the former. In the world of REXX, IBM has just released the ability to support pipes in the manner of unix when this could have been done ten years ago, and the pipe tutorial lauds something called "pipethink". This Orwellian word means that programmers will ALWAYS reuse code, and I believe it is deskilling. "Pipethink" will create programmers good at fitting together confusing pipe expressions which may (or may not) do a particular job, but able to survive ONLY in environments where (1) all the tools are in place and (2) all of the tools work as advertised. Reusability AND the ability to make things reusable are both attributes of the skilled programmer!