Subject: Re: garnet performance issues From: Erik Naggum <erik@naggum.no> Date: 1999/02/12 Newsgroups: comp.lang.lisp Message-ID: <3127770573291217@naggum.no> * Duane Rettig <duane@franz.com> | Coming from a hardware background myself, I grew up learning the | importance of the prototype, and have always been aware of the truth in | the adage "Always throw the first one away". I am a bit surprised at how | few programmers buy in to this truth, especially given how easy it is to | change software relative to hardware (yes, even C++) [perhaps not as true | as it once was, in this throw-the-old-chip-away era, but it was certainly | true 20 years ago; the equivalent of the chip filled a room back then, | and it was certainly not an option to throw it away]. since I recently said I don't believe in prototypes, let me clarify and expand on it: I don't think one should write software with the conscious intent to throw it away. instead, you should be prepared for that outcome, but work to make it the real system. after a while, you _may_ find that certain areas of the application domain were underresearched and find it easier to start over, but people who work on software that is known to become junk get quite disillusioned, and managers never give them the resources they need to make the prototype useful to learn from. instead, the first _real_ version will be the prototype that they wanted the prototype to be: the one from which they learn what they were really trying to do, so the prototype is a waste of time and money. add to this that many a manager feels this way about paying for software that isn't going to be the real thing and associates bad things with "prototype". since so many are quick to point out that Lisp is great for prototyping, the message is that Lisp is a great choice if you want to waste time and money. I think it's the other way around: if you are free to make all sorts of changes to the design with little impact on the system, what you end up with has probably learned all there is to learn from the iterative process that otherwise would have involved several languages, teams, and project managers. #:Erik -- Y2K conversion simplified: Januark, Februark, March, April, Mak, June, Julk, August, September, October, November, December.