Subject: Re: What Lisp to choose?
From: Erik Naggum <erik@naggum.no>
Date: 2000/06/06
Newsgroups: comp.lang.lisp
Message-ID: <3169295502388140@naggum.no>

* Martin Cracauer
| And what will you do if the vendors gives up the product, develops the
| product in a direction you don't like (i.e. it becomes unstable), if
| the vendors dies and noone picks up the product, if the vendor simply
| raises the price - maybe even for redistribution of runtimes - or if
| you need to support a platform the vendor does not support?

  This has a very simple and obvious answer: You do what you always do
  when "the world" dissolves underneath a programmer: You reimplement
  your software with the best available tools and people at that time.

  It's a strange illusion that just because it's in some "free" form,
  it's going to stay useful forever.  Operating systems come and go,
  languages change and their compilers and development tools with them
  -- including such fickle things as the support libraries that change
  in subtly incompatible ways all the time.  And let's not forget the
  people who can actually make use of the specific combination of all
  of these things -- people have two nasty habits: (1) they forget,
  and (2) they die.  All of this happens all of the time -- regardless
  of whether you have source code to something.  Even the hardware on
  which the last system in the world ran will deteriorate and die.

  What does using stuff that follows standard buy you?  _More_ time,
  not eternity, and not even necessarily _much_ time, either.  If the
  standard is _excellent_ and it's universally adopted by someone who
  is not so cavalier about standards as Microsoft, it may buy you a
  lot of time, like 15 years.  If it's a bad standard, it will also be
  improved.

  Reimplementing is part of the maintenance costs of a project.
  You're a damn fool if you don't calculate it into the price of
  something that is going to be in use for a long time.  It's very
  much like longevity in data storage: If you don't plan to have
  someone copy data off of old media onto new media to keep it alive,
  possibly converting it in the process, it _will_ wither and die.

| Setting yourself on a single-vendor API with only one implementation,
| with no source you may redistribute in an emergency case, is suicide,
| time-invenstment wise.  I've been programming for long enough to know
| this and who the specific vendor in question is couldn't matter less.

  Then you should also admit that there is _no_ cure.  Just about
  everything is suicide, time-investment-wise: Everything dies in the
  end and under more miserable conditions the longer it has been kept
  alive artificially, I might add.  The question is how much time you
  lose or fail to lose (but that is not "gain") with each move you
  make.  There is nothing to indicate that having source code access
  buys you any more time than not having source code access does, in
  the general case.  Specific cases may of course be cited the same
  way alternative medicine cites its successes.
  
#:Erik
-- 
  If this is not what you expected, please alter your expectations.