Subject: Re: How I lost my faith (very long)
From: Erik Naggum <erik@naggum.net>
Date: Sat, 23 Feb 2002 10:54:37 GMT
Newsgroups: comp.lang.lisp
Message-ID: <3223450480895611@naggum.net>

* Jon Allen Boone <ipmonger@delamancha.org>
| I have read that Lisp is good for building systems.  However, since all
| of my programming training is *exactly* of the sort that Erik describes,
| I have a hard time understanding what type of "system" Lisp is good for
| building.

  Well, I think using Frederick P. Brooks' terminology is the simplest way
  to answer this.  He ditinguished between a product (1), a programming
  product (3), a programming system (3), and a programming systems product
  (9), with his estimated factor of increased cost in parentheses.  For a
  particular product, you can probably do one version cheaper in some other
  language than Lisp, but add generalization and adaptability to future
  needs, and Lisp wins.  Add testing costs, and Lisp wins.  Add maintenance
  costs, and Lisp wins.  Add systems integration, and Lisp wins.  I also
  want to add correctness and cost of failures, because that is where it
  really takes resources to achive excellent results in most other
  languages.  Effectively, the Common Lisp environments are precisely the
  kind of programming systems product that Brooks talks about, and they
  cost at least two orders of magnitude less to develop than similar
  systems for C++.  Borland nearly croaked under the financial burden of
  its C++ environment, Lotus died, and similar stories abound.  A larger
  proportion of fairly small companies have over time been able to build
  and survive building Common Lisp environments than other languages have
  supported.  (Those that have died, such as Lotus, died not because of
  their Lisp operation, but because it was so successful that it could be
  milked to keep loss-making operations afloat too long.  Xanalys was the
  result of Harlequin's bankruptcy reorganization, but that was not due to
  losses in its Common Lisp business, which has thrived afterwards.)

  Of course, the cost of building Common Lisp environments is not a good
  metric of how useful the language is to build systems by itself, but the
  fact that you can do this with relatively little effort (even compared to
  such stunts as Perl, which I venture has cost much more development time
  than CMUCL, CLISP, or even Allegro CL), means that building something new
  on top of it should be equally productive, and a system for large CAD
  applications has been built with Allegro CL that is effectively a
  programmable CAD system.  There are number of such large applications
  that are not merely applicatiosn, but domain-specific programming systems
  products.  Of course, they cost hundreds of millions of dollars to build,
  and take whole herds of programmers to complete, but the success of these
  large things and their costs really show that Common Lisp has an edge.
  Also, the failure rate of such projects in Common Lisp is much lower
  than, e.g., C++.

| Until I can figure out what kind of systems Lisp is good for, I intend to
| try writing the only kind of software I really am suited to write: small
| tools.

  There is nothing wrong in that.  Quite the contrary, but you do not
  generally get into maintenance issues, documentation and tutorials,
  systems integration (except to integrate your tools in some other system,
  which is quite the reverse problem) in small tools.  Try to work on Emacs
  for a while, but do not get too influenced by the bad Lisp it uses.

///
-- 
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.