Newsgroups: comp.object,comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!das-news.harvard.edu!news2.near.net!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!agate!overload.lbl.gov!lll-winken.llnl.gov!fnnews.fnal.gov!gw1.att.com!nntpa!nntpa.cb.att.com!lgm
From: lgm@polaris.ih.att.com (Lawrence G. Mayka)
Subject: Re: Why Commit to Eiffel?
In-Reply-To: doug@monet.ads.com's message of 6 Sep 94 15:43:21
Message-ID: <LGM.94Sep12084718@polaris.ih.att.com>
Sender: news@nntpa.cb.att.com (Netnews Administration)
Nntp-Posting-Host: polaris.ih.att.com
Organization: AT&T Bell Laboratories, Naperville, Illinois, USA
References: <DERWAY.94Aug31155314@alumni.ndc.com> <344osc$dc7@gateway.wiltel.com>
	<1994Sep6.000222.10384@rcmcon.com> <34i9hc$qfu@disuns2.epfl.ch>
	<DOUG.94Sep6154321@monet.ads.com>
Date: Mon, 12 Sep 1994 13:47:18 GMT
Lines: 67
Xref: glinda.oz.cs.cmu.edu comp.object:20339 comp.lang.lisp:14616

In article <DOUG.94Sep6154321@monet.ads.com> doug@monet.ads.com (Doug Morgan) writes:

   I like Lisp, but this list seems to be make light of real problems
   with the Common Lisp standard (e.g., "Know thy compiler" can easily
   become an unproductive full-time job.)  Here is a sampling of details
   (possibly a few years out of date):

    7. No commercial shared library implementations. (How big is a
       hello-world Lisp process? How many run simultaneously on your
       computer and still start up in under a second?  I think some
       vendor's delivery techniques may have made some gains here, but
       don't know the details.)

I believe Allegro CL 4.2 uses a shared library for code vectors and
strings.  Keep in mind, though, that the need to run many UNIX
processes (i.e., heavyweight processes with private address spaces) on
a single machine is to a great extent an artifact of UNIX's design and
history, and C's lack of pointer safety.  An industrial Common Lisp
programmer is much more likely to use multiple threads (lightweight
processes) within a single address space, and indeed typically finds
this much more convenient for interprocess communication.

    8. No standard interface with UNIX signals (and the ones that exist
       can be like pulling teeth).

I shudder at the thought of anyone continuing to use UNIX signals for
interprocess communication in this day and age.  UNIX shared memory
becomes a nightmare for any data structure that includes pointers.
Even UNIX message queues and semaphores are seriously handicapped
because they don't cooperate, as far as I know, with multithreading
systems based on select() or poll().

    9. No free down-to-the-hardware full-up compilers.

GNU CL compiles to machine instructions.  The fact that it employs a C
compiler along the way is a common portability trick, used by other
languages as well.  I admit, though, that I'd like to see the GNU C
compiler backend folded into GNU CL, if only for the sake of
compilation speed.

   18. No standard way to find the declared type of a symbol.  (Also,
       can't macro expand a declare, must expand an entire construct.)

Yes, I was sorry to see VARIABLE-INFORMATION and FUNCTION-INFORMATION
dropped from the standard.

   23. Maybe Dick Gabriel had a good point in saying that Lisp is "the
       right thing" but that the "worse-is-better" C++ approach is
       destined to win.  Of course, Lucid lost on both big-time, so maybe
       there is a grain of salt to be taken with his assessment.  Also,
       if the vendor-base isn't shrinking, it sure doesn't look like new
       Lisp vendors are brewing up like storm clouds before the downpour.

As someone has already pointed out, rumors claim that Lucid's C++ was
its downfall.

I would not expect a brew of new vendors for =any= industry that is
becoming more capital-intensive (i.e., requiring more effort to stay
abreast of market demands).  Capital-intensive industries tend to
reduce to the "Rule of Three (or Two)", whereby only 2 or 3 major
vendors remain, with other vendors reduced to niche status.
--
        Lawrence G. Mayka
        AT&T Bell Laboratories
        lgm@ieain.att.com

Standard disclaimer.
