Subject: Re: garnet performance issues
From: Erik Naggum <>
Date: 1999/02/12
Newsgroups: comp.lang.lisp
Message-ID: <>

* Duane Rettig <>
| 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.

  Y2K conversion simplified: Januark, Februark, March, April, Mak, June,
  Julk, August, September, October, November, December.