Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!mcsun!cernvax!chx400!sicsun!disuns2!/!baechler
From: baechler@disuns2.epfl.ch (Emmanuel Baechler)
Newsgroups: comp.lang.clos
Subject: Re: CLOS' popularity
Message-ID: <1991May30.082921@disuns2.epfl.ch>
Date: 30 May 91 06:29:21 GMT
References: <9105131105.AA13630@hcsrnd> <9105181833.AA05092@rice-chex> <1991May28.033548.26907@cs.cmu.edu> <4846@skye.ed.ac.uk>
Sender: news@disuns2.epfl.ch
Reply-To: baechler@disuns2.epfl.ch (Emmanuel Baechler)
Organization: Ecole Polytechnique Federale de Lausanne
Lines: 68
Nntp-Posting-Host: disuns2.epfl.ch

In article <4846@skye.ed.ac.uk>, jeff@aiai.ed.ac.uk (Jeff Dalton) writes:
> 

> 
> For years, I have been hearing that it doesn't matter that Lisp
> requires vast amounts of memory, because menory is so cheap.  For
> years, I have been hearing that it doesn't matter that Lisp is
> so poor at delivering applications because it's so great at
> development.

  The amount of memory doesn't matter: memory *IS* really cheap today,
and SparcStations are cheap CL platforms. In addition, they are really
quick at running lisp. They are so quick, that I doubt more and more that
there is a provable speed difference with C (for applications of the same
style). Their environnment remain primitive, compared with a lisp machine,
however they are usable, and much better that the environnments of imperative
languages.

  All the Common Lisp implementations I know are now sold with CLIM, which
allow to generate user interfaces in a much more convenient way than directly
programming X11. And I do not see any reason why it should be necessary do
manipulate directly X11, while much higher level tools are available.

  Finally, Franz Inc (but I guess Lucid too) has a tool to generate standalone
applications, with a minimal lisp kernel, such that the customer do not even
see that its application has been built in Lisp.

> 
> Quite a bit can be accomplished by picking the right implementation,
> but it's a pain to end up using several varieties of Scheme and Common
> Lisp in order to get reasonable results.  Too many implementations of
> Common Lisp seem to have decided that it hardly matters how big they
> are, thus leaving many users with too little choice.
>

  How big is X11, Gnu Emacs, AutoCad, LaTeX? Everybody complain while CL 
looks big, while none does about all our other favorite tools, which are
frequenlty as big, and require quite a lot of memory too.

 
> It's convenient to think that Lisp will survive as a development
> tool while other languages are used for applications.  What may
> happen instead is that (a) development tools for other languages
> will improve so that Lisp's advanatges are less great, (b) Lisp's
> reputation as too big and slow will cause many people to think
> it will be faster to start in C rather than switch to it later
> on, and (c) as Lisp is used less there will be less incentive to
> learn it or teach it.  

Lisp will srurvive both as a research and a developpment langugage,
because its PRACTICAL power and extensibility make easier to do 
sophisticated things: they can be programmed at the level required
by the problem, instead of "putting down" the problem at the level
of the language. The "leading" applications in a few years will be
much more sophisticated than the current ones. They will deal with
diagnosis, scheduling, financial and economic analysis, ICAD and so
on, and these applications are *MUCH* more easily programmed in
a high level language like Common Lisp than C, which is just "the
power of assembly language with the flexiblity of assembly language"
as someone said.

Emmanuel Baechler
baechler@liasun4.epfl.ch
AI Lab.
Ecole polytechnique Federale de Lausanne
MA - Ecublens
1015 Lausane
Switzerland