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

* Duane Rettig <>
| Your arguments sound like the "quality" argument (i.e. "do it right the
| first time", "strive for zero defects"), and mine comes from a slightly
| different point of view that I believe is in harmony with the quality
| perspective, but which is often forgotten.

  um, no, not quite.  I don't believe it is possible to do anything right
  until you know what "right" means, and this is not available a priori,
  despite what all the lectures in programming methodology and systems
  design would have poor students believe.  (if it was, we would have had a
  perfect society, too -- law is nothing more than programming society, so
  if it were possible to plan for everything, it would have been worked out
  many millenia ago.  I'm amazed that people think large-scale experiments
  in top-down design like dictatorships and planned economies would fare
  any better in any other endeavor involving creative people.)  therefore,
  you have to go through various iterations, and your design must be
  prepared for this, but that is not to say that you should _not_ expect
  success, or actively prohibit it.

  the issue I want to raise is whether people should approach the first
  version with "let's try to get this right" vs "we're going to throw this
  one out, so let's not waste too much resources on it".  the whole point
  with wasting the first version is to waste _only_ the first version, at
  worst.  people who set out to do something that will be a waste in the
  eyes of managers who cannot understand why their employees do not know
  enough to get it right the first time, will _not_ learn all there is to
  learn and will _not_ ensure that only the first version gets wasted, but
  will waste version after version.

  now, if they do get he first version right, and don't need to waste it at
  all, that's a very commendable result, but if you only set out to
  "prototype", this is no longer an option, either by choice of language or
  tools or something else that everyone knows was intended to be wasted,
  and would feel bad if it were to go into production.  that's what I think
  is wrong about using specific languages to prototype things and talk
  about a language as "good for prototyping".  it is invariably understood
  as "not good for production code".  I have to fight this impression.

  in conclusion, it is hard enough work to it right the second time when
  you have all the data from the first try available if you should not also
  have to do it a third time because you weren't _allowed_ to go all the
  way in the first attempt.

| Another way to put it is "Don't hang on to the first thing you did."

  my argument is that the reverse is equally valid: don't _always_ throw
  out the first thing you did.

| However, I submit that lispers prototype constantly, and that every time
| you type "(defun foo () ...)" to the prompt, you are prototyping
| something that you _intend_ to throw away (otherwise you would have put
| it into a file!).

  ok, that's the gist of your disagreement.  I think intent to throw away
  is the bad part about prototyping.  throwing away is something you should
  be prepared to do without much concern, but you should strive to make it
  usable, too.  if you intend to throw it away, the threshold to keep it is
  set too high.  now, what if it actually does work the way you wanted it
  to?  do you still throw it away?  if you prototype in Lisp and write
  production code in C, you would have to, right?  that's bad.  not only
  because doing something you have already done over again is stifling, the
  problems in C are different from the problems in Lisp and you have to do
  a lot of redundant work. 

| The world is full of programmers stuck on their own dinosaurs because
| they won't let go.

  well, letting go is as much a part of caring about something as not
  letting go.  sadly, our cultures are built by people who couldn't let go,
  so everything around us is shaped by an unhealthy conservatism, and
  because people are afraid of having to suffer as much pain every time
  they manage to get something to work somewhat right, we have a lot of
  stuff that were shaped by a trial-and-error process that stopped as soon
  as the errors were tolerably small.  had people been able to let go, and
  use their knowledge from what failed, perhaps we could move on.  in my
  view, the patent system was supposed to let inventors capitalize on the
  works of others and make _significant_ improvements, while the patent
  effectively forbade the meager insignificant improvements.  a wonderful
  mechanism that should be applauded and made much stronger, it has turned
  into a monster that stifles innovation by admitting overly broad and
  senseless patents, instead because the wrong kind of people approve
  patents.  this is just another example of how society is shaped by
  conservatives who have no clue _what_ they are conserving, only that
  change is bad.
| In which case you have already rewritten (at least parts of) your
| application several times over.  But to be free to do this rewriting, you
| have to have made a correct estimate of how long the project will take.
| If you factor in the prototyping (call it "learning curve", or "concept
| development") time, you will have the time to do this.

  ironically, you always have time to do that, despite what everyone says.
  the key is to get something to the point where it does not fail, and then
  you can change everything as long as it continues not to fail.  people
  always have time to improve things, and they embrace things get improved
  in oh so minor ways.

| But if they hear bad news from someone they know can and has done the job
| on time in the past, they tend to be much happier than when they hear
| good news from someone that they know they are going to have to plan
| "slop" time for.  And for those programmers who gain the reputation of
| getting work done on time, the subject of prototyping should rarely even
| come up.

  well, there's often a "fuzz factor" you can add to or multiply with what
  people say.  a good manager learns the fuzz factor and doesn't want to
  change it.  some programmers get all the big work done in the first few
  days and then spends a lot of time fixing minor bugs, while others tinker
  with fundamentals 95% of the time and whip up a marvelous piece of art in
  the last few days.  the key to managing is to understand what you deal
  with, and programmers are predictable _one_ at a time, even when they are
  (supposedly) part of a team.

  incidentally, getting something to work is child's play.  where you need
  the expertise is in not making it fail, or fail gracefully.  and I don't
  think a prototype that only shows how it works is useful at all, since
  you learn nothing about surviving the failure modes by having something
  that only "works".

  anyway, I like Common Lisp because I can write enough serious code in it
  to watch how it actually deals with a hostile world (specifically, socket
  code that distributes functionality across hundreds of computers over
  thousands of little stretches of cable and routers that people upgrade
  and add bogus routes to and all kinds of shit) and then rewrite it before
  the hostilities resulted in harming anything.  also, Allegro CL is the
  first environment I have used which allows me to use all I know and learn
  about the hostile world without writing tons and tons of code.  when
  something causes a crash only once a year, you ignore it in C because it
  might change your whole design and basically send you back to the drawing
  board for a year to deal with it, and then you suffer a crash once a
  year, so it isn't worth the costs.  it might take a week or a month to
  redesign to survive such a problem in Common Lisp, but you can actually
  offord to take care of it.  this means that the next time you have to
  deal with this kind of problem, the competent Common Lisp programmer gets
  it right, while the competent C programmer still doesn't know what it
  would take to solve that particular problem because he hasn't been there.

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