🚀 go-pugleaf

In article <1991May28.033548.26907@cs.cmu.edu> ram+@cs.cmu.edu (Rob MacLachlan) writes:

   From: ram+@cs.cmu.edu (Rob MacLachlan)
   Newsgroups: comp.lang.clos
   Date: 28 May 91 03:35:48 GMT

   I am a Lisp implementor, and a Lisp advocate, but I think a lot of damage has
   been done by advocating Lisp as being:
       "The same as FORTRAN/C/Ada, only better". 

I agree with much of what has been said in this thread but would like to
add something as well.  I believe there is a chance for Lisp to succeed
as a commercial language, and moreover as a commercial language used in
delivered systems.  But, before this can happen a number of current
obstacles to using Lisp together with other languages must be resolved.

Here a simple analogy I use when thinking about this.  When you build a
car, or an airplane, or a building, you don't build it out of one single
material, nor do you use one single tool.  (Ford doesn't build cars out
of steel only with screwdrivers only.)  It just wouldn't make sense to
do that.  A car is a complex system, its various parts must satisfy a
variety of goals.  The simple fact is that different materials and
manufacturing techniques do a better job of meeting those different
goals.  While there are a few zealots who argue that everything should
be built out of plastic or ceramics or some other wonder-material, the
common practice is not to do so.

Similarly modern computational systems are large and complex and have
components which must meet a variety of goals.  It doesn't make sense to
try and build all of these parts out of the same substrate.

Take for example a modern photocopier.  The tasks which much be handled
include: real-time control (for the paper path and imaging system),
window-system like UI functionality (for the control panel), signal
processing (for copy quality adjustments) and data logging (for the
billing and fault-prediction system).  There is no reason to believe
that a single programming language, or even a single operating system,
is appropriate for all these tasks.

We need to understand what tasks Lisp is good for and do a better job of
characterizing them.  Then, in order to make it possible for Lisp to be
used as part of larger projects, our job, as technicians, is to try and
work out the technical obstacles to writing large systems using a
variety of languages and libraries.  The job of our marketing
organizations is to try and work out the financial and legal obstacles
to writing large systems this way.

Only when both of these jobs are done will users be free to write
systems in which each individual part can be done using the best tool
for the job.  Until then, users will continue to use a single tool for
the whole job.  As long as they are forced into that kind of situation,
I think its fair to say they will choose C more often than Lisp.