I think Lisp implementers should take this as a wake-up call.

There are other warnings.
  * Lucid went out of business
  * CMUCL was abandoned, and the people are working on Dylan
  * MCL was abandoned for 2 years before being revived
  * The GARNET project has left lisp behind and has gone to C++.
    It's now 3 times faster, and more people are interested in it.
Surely there are many others.

As far as I can tell, ANSI lisp is being treated as a huge
plateau, as if there is nothing interesting left to do, or
as if any further changes would be too hard to negotiate.

What about speed?  size?  C/C++ interoperability?

These issues have been untreated emergencies for some years now.

Since the reviewer was anonymous it is particularly hard to draw conclusions
about whether they view Lisp as Lisp 1.5, or to verify such conclusions.
Possibly the anonymous reviewer had a very clear understanding of the
current state of Lisp, but was concerned about the issues of viability that
Yost mentions.

The sentence quoted is interesting because it seems to mix two concepts:
"Lisp as a viable system environment" and "Lisp as a line of research".
(Of course, the quoted sentence may really be talking about something else
as a line of research, but it brings to mind the idea that Lisp itself
has been developed as a "research language" -- a language for doing
research about AI and other topics, and an environment for doing research
about the design of powerful programming languages.)

Possibly the reason Lisp is in the state is in today is that historically
these concepts have always been mixed, and perhaps not well balanced.
This has led to a language with the perceived efficiency and space
problems that Yost mentions.

: Denial.

: I think Lisp implementers should take this as a wake-up call.

: There are other warnings.
:   * Lucid went out of business
:   * CMUCL was abandoned, and the people are working on Dylan
:   * MCL was abandoned for 2 years before being revived
:   * The GARNET project has left lisp behind and has gone to C++.
:     It's now 3 times faster, and more people are interested in it.
: Surely there are many others.

: As far as I can tell, ANSI lisp is being treated as a huge
: plateau, as if there is nothing interesting left to do, or
: as if any further changes would be too hard to negotiate.

: What about speed?  size?  C/C++ interoperability?

: These issues have been untreated emergencies for some years now.

: Dave Yost

Perhaps the solution is to separate the concepts, not mix them, and
focus development of Lisp along three parallel paths:

1) Lisp as a viable system development platform. A subset of CLOS
that can be implemented with small memory requirements, compiles just as
efficiently as C, yet retains more value than C or C++ in terms of
productivity and built-in language constructs.  This could be very
attractive to current systems developers.  It might even resemble
Lisp 1.5 ;)

2) Lisp as a language for research projects.  Perhaps the full CLOS as
we know it, or perhaps CLOS extended along lines that support particular
topics in AI research.

3) Lisp as a language for research about programming languages.

I have to agree with Dave Yost; In many respects, modern C/C++/Visual
Basic development environments rival or exceed the best lisp has to
offer.  The underlying language is still crap, but the gloss on top of
it demos really well; and truthfully, goes a long way toward improving
productivity.

Despite many millions that went into Symbolics, LMI, TI and Xerox
(both directly and to their customers) there is not *ONE* really well
known "lisp" success story to point to; and on the flip side,
everybody knows how much was invested in those companies, and where
they are now.

The remaining lisp vendors are locked into survival mode, and don't have
the resources or inclination to undertake anything revolutionary.  The
supply of new blood from the universities is thin - all the up-and-coming
wizards are into networks and multimedia.  

In short, lisp is well on its way back to where it always was; as an
amusing backwater of the computer industry; of interest only to a few
academics trying to do things that are completely impractical anyway.

|   Saying "but we've got it right" to each other 1e6 more times isn't
|   going to convince anyone new.

but it might convince a person or two to try it out and bring some ideas
back to the other cavemen.

if it weren't for the fact that numerous excellent Lisp systems exist for
my SPARCstation, I would probably have sold the machine and gone fishing
instead of suffering C++ and the general cluelessness of the PC industry.
every week or so, another student at the Department of Informatics at the U
of Oslo shows interest in Emacs Lisp and Lisp programming because some of
us keep posting neat functions in Lisp.  there are those who are attracted
to the elegance of Lisp even though there is little paid work to get using
it.  come to think of it, this is how many of our best programmers approach
_programming_, not just programming languages.

besides, I couldn't have worked with C++ for a year without Emacs Lisp to
help me write in that language.

Saying "but we've got it right" to each other 1e6 more times isn't
going to convince anyone new.

Another Lisp success story was Desert Storm.  Much of the logistics was
done using Symbolics Lisp.

Instead, we will see an increasing number of `hybrid' applications
that are written in a mixture of Lisp (or actually a dialect thereof,
such as Scheme) and C or C++.

And it's about time; Emacs has been around for many years, and it
works and has been successful.

Lisp is considered too hard for most programmers,
too elegant, too complex, too formal, etc.
A Vice President of a major computer industry company
said this (more or less) to me just the other day.

I think this problem could be solved by
the right book, targeted directly at C programmers.

Lisp is as great as it is because there are many, many
things about Lisp that don't come easily to a C programmer.
Most of them I think are ramifications of the fact that
Lisp is a dynamic environment.

Perhaps someone could do a survey people who still
remember what they went through to transition from C to
Lisp and collect a list of things they found difficult
or hard to get used to.

Guess what, from what I've seen during twelve years in the industry,
*programming* is too hard for most programmers.

I am not kidding. Any language. Most can't do it very well,
and I'm tired of dealing with those who can't.

--
Patrick_D_Lo...@ccm.jf.intel.com
Intel/Personal Conferencing

We Lisp users are fighting more than a battle between
technologies: it is a struggle of giant viruses that take hold
of our brains and grow within us in irreversible symbiosis.

How often have you asked yourself `is Lisp really that good
or have I been zombified by using it this long?'  How often
have you seen someone talk about Prolog with the same inspired
expression you use when you describe some Lisp feature, and
you thought `how can he be so blind?'

Given enough time, people will like even something like C++.
By then, their thinking processes will be so enmeshed with
C++ that not liking C++ would mean not liking their own brain.

I know this happens and it worries me because I am afraid
it's something I cannot rationalize.  For instance, I see
people more and more often put C and C++ in the same ballpark.
How can they be so blind?  To me C is a small language, with
serious limitations but a precise rationale: easy to learn,
and, within that rationale, quite consistent.  C++ on the
other hand feels like the result of carrying that same
rationale into a realm where it no longer makes sense.  
But I have programmed in C a lot more than C++.  So what
do I know?

I say this because that's how people on the other side see us.
To them we look just as blind as they to us.  This is the
fundamental obstacle.  It's not object orientation or image
size or programming environment.  It's whatever you learn first.

Maybe we should shame all programmers into taking on lisp,
as a test of mental strength, and if they can't hack it
maybe they'll give up and try another line of work.
Hey, maybe management!    ;-)

I agree with the warnings sent by Dave Dyer and most
comments thereafter. However, I think one number is off:
at least one language costs a lot more money to develop than this...

On 6 Jun 1995, Dave Yost wrote:

     Programmer's Wanted, $100/hr.
    Knowledge of Lisp, C++ required.

Whenever anyone calls up, you just tell them that their Lisp experience
is inadequate. At least it would increase book sales.

Hubble Telescope planner: written on TI Explorers in late 80s. (no it
wasn't used to design the mirror)

SwissAir: their flight scheduling (?) program, also written on TI
Explorers (I bump into these folks when I try to buy used hardware
sometimes, as they can outbid me).

Chicago Board of Trade: futures trading program, on TI microExplorers.

I don't know where any of them are now.

I've programmed in a few different langauges and worked with a bunch of
different programmers. I find that too many of those programmers used the
"try stuff until it works" debugging method. They try something. OK that
doesn't work. They try something else. Ok that doesn't work. So they try
something else. That works. Bug fixed. This makes a huge mess of a piece
of software because it turns a relatively straight forward piece of code,
that may have not covered every contingency, into a patchwork of partial
fixes.

I absolutely hate coming onto a project and seeing code like this. In most
cases I end up rewritting huge protions of the code. I usually finish
before someone who is just fixing things because I turn the messy
patchwork into clean simple code and they just fight the patchwork.

I don't find programming in any one language harder than any other. I find
programming in a particular implementation harder than another. I also
find that some problems take longer to solve in one langauge than another.
I find having to deal with all of the details of memory management in C to
be a pain in the butt. Sometimes I feel like I'm writing the same code
over and over. On the other hand trying to poke around in the internals of
the OS from Lisp is a pain in the butt. (Some Lisps are better at this
than others but doing it in C is easier. At least I find it so.)

I've found Lisp one of the easier languages to work with. Some of the
reason is the excellent environment that comes with Macintosh Common Lisp
and some of it is because I don't find myself programming details as much
as much as I do in C.

Yes, there's a strong leaning toward one's favorite language, and
yes it does color one's perceptions of other languages, particularly
those that are a sufficient "distance", cognitively, from familiar
territory.

What's really frustrating is that the cross-pollination of ideas is
so pathetically slow, mostly because people's natural tendency is to
block out anything far from their self-perceived norm...  That's why
C++ users absolutely fawn over new clever ways of writing data structures
like (to quote an example from a magazine that crossed my desk today)
"arrays of arrays" -- a big yawn to Lispers.  On the other side, I'd
kill for a really natural interface to the underlying OS, or a GUI
framework as robust as those taken for granted by C++ users.

Even languages as conceptually close as Common Lisp and Scheme suffer
from the cognitive gap.  And as a Lisper, how well do you think Dylan's
infix syntax (an idea being reborn for the Nth time in a Lispy language)
will fare with die-hard Lispers?

Look, for instance, at all the "numerical methods for C" type books that
are republications of code written originally in Fortran in the 60s....

Here's the trick to maintain academic honesty while seeming completely original:
write a TR with full references to the lisp literature, then write your paper
for whatever C++ conference you like, but only reference your TR. Nobody will
ever bother getting the TR but other university types, and WHO CARES, you're
after the real job in industry that pays 6 figures, not a publish or perish
rathole that barely covers rent. Of course, even if you want to go in that
direction, there's only about 45 years of lisp results waiting to be
republished in C++ journals.

Remember that nobody reads anything that isn't "in their language", be it
computer programming or political spectrum. There's millions of ideas most
people will never bother trying to adapt to their own technology, because
they can't be bothered to learn to look under the surface syntax.

The program's called spike and it runs on more than one commercial lisp
system.  It was used for scheduling on the Japanese X-RAY ASCA mission (an
X-RAY telescope) and will also be used for the US XTE mission (another
X-RAY telescope).

The first is comprehensibility.  In the case of Lisp, there is the
sheer size of the language.  It prevents all but a few from ever
getting a feeling that they have really mastered it; in fact, it
leaves most with the sense that they have only scratched the
surface.  Scheme is much better here.

Then there is the problem of abstractions.  Lambda, one of the key
things that makes Lisp & friends so nifty (you can make functions
on the fly, have functions returning other functions, create
closures, etc.) is a DIFFICULT CONCEPT.  Look folks, we have
trouble teaching them what ordinary mathematical functions are, let
alone functions of higher type (a.k.a functionals or operators).
(Actually, I have hopes that teaching a Lisp dialect will help
students learn mathematical concepts!  So I'm not objecting to
abstractions, I'm only pointing out that for the beginning
programmer they're a source of difficulty and complexity that must
be addressed.)

Another aspect of comprehensibility: In my view, most people reach
an understanding of how a programming language "works" by
constructing a mental model of the computer and how it executes the
statements of the language.  C is close to an assembly language, so
the mental models (which change as learning occurs) reach a good
approximation of reality in a relatively short time, and thus serve
as reliable predictors of what a particular piece of code is going
to do.  The reality of Lisp implementations is relatively
complicated, and the mental model must also be more complicated.  I
spend some effort explaining "how it all works" to students, but
however useful this may be, it does add an extra layer of
complexity.

There is the problem of efficiency.  I don't mean whether the
compiler can generate fast code.  The problem is seeing whether one
has written good code or not.  It is hard to tell.  I have a friend
who maintains a large Lisp program written years ago by others.
Often, he comments on what poor code is there, and he improves it.
But the original coders were hardly Lisp neophytes; why didn't they
see how bad the stuff they were writing really was?

Program size: as Barry notes, even "hello world" can be huge.  How
important do you suppose it is that student programmers and other
learners be able to create small programs that they can pass around
to friends?  Some don't care but many do.  If I write a piece of
Lisp code for some simple string manipulation, I may find it very
useful myself, but I might actually be embarrassed to offer the
complete stand-alone application to anyone unfamiliar with Lisp.

Accessibility: Good C compilers are available, are cheap, and fit
on relatively small student-owned machines.  Having your own system
on your own machine is a big plus for anyone learning a language.
It isn't a requirement, but it helps.

Debugging: Most Lisps have pretty serviceable debugging tools.  But
what if your code breaks something at a low level?  It's pretty
easy to tell what piece of C source some assembly code corresponds
to, but not so for Lisp.  And there are other difficult situations:
I've been scratching my head for a while over one where the
compiler chokes on code produced by several layers of interacting
macros.  It is bewildering trying to figure out where this code
originally came from!

The first is comprehensibility.  In the case of Lisp, there is the
sheer size of the language.  It prevents all but a few from ever
getting a feeling that they have really mastered it; in fact, it
leaves most with the sense that they have only scratched the
surface.

Then there is the problem of abstractions.  Lambda, one of the key
things that makes Lisp & friends so nifty (you can make functions
on the fly, have functions returning other functions, create
closures, etc.) is a DIFFICULT CONCEPT.  Look folks, we have
trouble teaching them what ordinary mathematical functions are, let
alone functions of higher type (a.k.a functionals or operators).
(Actually, I have hopes that teaching a Lisp dialect will help
students learn mathematical concepts!  So I'm not objecting to
abstractions, I'm only pointing out that for the beginning
programmer they're a source of difficulty and complexity that must
be addressed.)

Yet another comprehensibility issue: I believe that most people
reach an understanding of how a programming language "works" by
constructing a mental model of the computer and how it responds to
language constructs.  This model changes as learning occurs.  In
the case of C, the language is close to the hardware, and it is
relatively easier to arrive at a mental model that is a serviceable
approximation to reality.  But the reality of Lisp implementations
is much more complicated, and calls for a more complicated mental
model.  So students spend more time blundering around, wondering
why things happen the way they do.  I spend some time explaining
"how it all works", but there's little doubt that this adds to the
perceived complexity of the whole experience.

There is the problem of efficiency.  I don't mean whether the
compiler can generate fast code.  The problem is seeing whether one
has written good code or not.  It is hard to tell.  I have a friend
who maintains a large Lisp program written years ago by others.
Often, he comments on what poor code is there, and he improves it.
But the original coders were hardly Lisp neophytes; why didn't they
see how bad the stuff they were writing really was?

Program size: as Barry notes, even "hello world" can be huge.  How
important do you suppose it is that student programmers and other
learners be able to create small programs that they can pass around
to friends?  Some don't care but many do.  If I write a piece of
Lisp code for some simple string manipulation, I may find it very
useful myself, but I might actually be embarrassed to offer the
complete stand-alone application to anyone unfamiliar with Lisp.

Accessibility: Good C compilers are available, are cheap, and fit
on relatively small student-owned machines.  Having your own system
on your own machine is a big plus for anyone learning a language.
It isn't a requirement, but it helps.

Debugging: Most Lisps have pretty serviceable debugging tools.  But
what if your code breaks something at a low level?  It's pretty
easy to tell what piece of C source some assembly code corresponds
to, but not so for Lisp.  And there are other difficult situations:
I've been scratching my head for a while over one where the
compiler chokes on code produced by several layers of interacting
macros.  It is bewildering trying to figure out where this code
originally came from!

So who needed to invent CORBA (today) when you could distribute objects
(agents) on a network of Lisp machines 10 year ago, plus you could use
TeleRaid and friends to remotely debug OO software distributed across
the network. I really thought these concepts would take over the
world of computing... And yes they did. I have seen every single successful
software vendor steal these concepts one by one, canibalize them and
make them so huge ever since.

Heck, Xerox invented fast windows on CPUs that probably were
20 times slower than the Pentium and at a time when having a 20MBytes hard
drive was a luxury! And look what happened to X windows and MS Windows.
When I look at the computer on my desk with 10 years of evolution behind it,
I see:

"Monster inside"

Written all over it!
Q: How can an industry go so wrong?
A: With lots more money, zero sense of Ethics and zero Knowledge
of its own history.

So where are we today?  People _love_ development by debugging blank
screens, so the newest tools for 'Visual Cxx' support this mode.  This
mode has become almost classical, now that it has the fashionable name
of 'fast prototyping'.  So the bullshit reasons why people didn't like
Lisp are just plain _wrong_, because nearly every one of these ideas is
heavily used today.

No, I think the real reason why people don't like Lisp is that people
(especially researchers at large companies and large universities) don't
like to admit that they were wrong, and that some snot-nosed kids got it
right the first time, perhaps decades before they did.  Therefore, after
5-10 years and a blizzard of technical papers, they change the names of
things and start touting the same things that Lisp had first.

Remember garbage collection?  Remember interpreters and incremental
debugging?  Remember incremental compilers?  Remember incremental loading?
(I could go on for _days_.)

People complain about 5 Megabyte 'hello world' programs.  Have you ever
measured the size of a RISC 'hello world' program that runs on a GUI
interface these days, with X-Windows (or equivalent), etc., etc.?  You
might be shocked and amazed.

The 8 Mbyte main memories required to run Lisp Machine Lisp grossed everyone
out in 1980.  But look at what it takes to run MS Windows these days!
16 Mbytes!  So it isn't the _language_ that cost all of the memory, but
the _functionality_.  And I'll bet that Lisp was at least an order of
magnitude more efficient in its use of that memory than MS Windows is.