If you keep an eye on the comp.lang groups, you'll find many articles
on Perl and TCL, for example, and next to none on Lisp.  For example,
I haven't kept up with News for the last few days, but my
comp.lang.perl has 338 unread entries, comp.lang.tcl has 171, and
comp.lang.lisp has 15.  Why is this?  Is is that these newer languages
have more problems to solve and require more discussion, or is that
Lisp, for whatever reasons, is not being used very much.

Regrettably, I suspect the latter and wonder what can be done to renew
interest in Lisp.  It seems like Lisp had a shot at widespread use in
the late 80's during the initial commercialization of expert systems,
and fell into disrepute because it didn't fit well on the hardware of
that era.  For example, Gold Hill Common Lisp was probably the best
publicized, best capitalized attempt to take Lisp mainstream, and,
speaking purely as a customer rather than a developer, it sure looked
like they had to struggle with the limitations of fitting it all onto
an Intel 286.  Meanwhile, some of the best minds of the era took a run
at doing it right with hardware, and we all know how LMI and Symbolics
turned out!

It looks like it's going to be a good language; I'm rooting for it.

|   (Open invitation to be flamed, but it's an honest question ...)
|  
|   If you keep an eye on the comp.lang groups, you'll find many articles
|   on Perl and TCL, for example, and next to none on Lisp.  For example, I
|   haven't kept up with News for the last few days, but my comp.lang.perl
|   has 338 unread entries, comp.lang.tcl has 171, and comp.lang.lisp has
|   15.  Why is this?  Is is that these newer languages have more problems
|   to solve and require more discussion, or is that Lisp, for whatever
|   reasons, is not being used very much.

where did you get the idea that USENET is representative of anything other
than USENET?  please note that both perl and tcl are net.creations, so you
should expect massive discussions on the net on these languages.  besides,
they are obviously broken, and anyone can come up with semi-reasonable
suggestions for fixes.  since they are also obviously useful, many people
will run up against their limitations while still enthused about what can
be done in either language, spurring discussions and more or less helpful
advice from others who have problems.  the obviously broken/obviously
useful scheme may not explain everything in computerdom, but I find its
explanatory power to be somewhat disconcerting.

reading the comp.lang.c and c++ groups, I get the impression that these
languages are perceived as "necessary" by people who wouldn't know a clue
from a bug.  is that a measure of success?

I'm not denying that you have a point, yours just isn't the only conclusion
that can be drawn from the available data.  I don't even think yours is
relevant outside of USENET.

|   Whatever the reasons, a language that embeds four decades worth of
|   solutions to problems is languishing while people jump aboard new
|   languages only to gradually rediscover the problems.

welcome to mankind.  I have good friends here at the U of Oslo who think
that Lisp gives them "cobol fingers", despite the fact that a raw character
count of their C programs compared to my Lisp functions indicate the exact
opposite, and similarly for their perl scripts, although the margin is much
smaller with perl.  the notion seems to be: "if you can't run it from the
command line, it ain't worth it".

all we need to do (he said, knowingly) is to make a hell of a Unix shell
that has the simple and easy access to the underlying system that perl and
a plethora of Unix "utilities" afford.  perl sucks, and everybody knows it
does, but it's just incrementally better than writing C, sed, awk, etc,
code to solve small problems.  Lisp isn't only incrementally better, it's
lightyears ahead, and then people think they will have to make a big
investment to get there, which is false.  anyway, this is why I think Dylan
went for its infix syntax.

|   So I'll ask it again: what would it take to make Lisp into a contender?
|   Maybe we can do something about it given that corporate America is
|   finally waking up to the fact that the COBOL era has ended and the
|   successor language is not yet identified.

all we know is that it isn't C++ or the current crop of "new" languages.
lots can be said against COBOL, and is, but it is a _stable_ language.
ironically, Common Lisp just recently became an ANSI standard.  I think
this will spur more involvement and interest, but it's hard to predict such
things.  who would have predicted that a technical loser like the WWW
should overtake FTP in packet count on the NSFNET backbone?

sure it is. it's called C. it's just like "buying IBM": no one ever lost
their job for writing something in C.

I've gotten cynical about it. my time doing Lisp work is drawing to a
close...sigh. at least my LispMs still work. I finally did some mods to
my news-reader last week to incorporate "kill-file" behavior. now if I
could just get the articles sorted properly...

 -- clint

I can offer several reasons why Lisp is not catching up.

1. Public choice.  Choosing a programming language for a large
community is a bit like democratically electing a government, and
don't tell me we do a good job at that.

2. Most people don't like math.  Lisp self-reflecting ability
(Lisp code is a Lisp data structure) is unmatched in other languages
and it is one of its most powerful features.  However, using it
requires slightly more abstract thinking than most people are
comfortable with.

3. History.  Cycles and memory used to be expensive.  Perl and
the other `scripting' (yech) languages are as slow as sh, but
better.  Few people think of Lisp as a replacement for sh,
but rather for C or C++.

4. Competition.  Lisp has serious competitors (although they
aren't catching up either ;-).  Lisp's solutions are not the
only good ones.  For instance, dynamic typing in Lisp is
often just a substitute for polymorphism, which is handled
quite well by ML and ML-like languages.

The view at Franz is that CommonLisp/CLOS was just ahead of its time.
10-15 years later its time is starting to come around.

Which is why the commercial world hasn't liked lisp as much as
academia and research - you see if you get paid well you're not
supposed to be having fun: so you had better be writing in
SQL and C++ or Visual Basic so you can me miserable and have lots
of money with which to have fun _after_ work.

It's all down to the Puritan work ethic! It has nothing to do
with technical judgement. But everyone knows that... ;-)

   |> Whatever the reasons, a language that embeds four decades worth of
   |> solutions to problems is languishing while people jump aboard new
   |> languages only to gradually rediscover the problems.  So I'll ask it
   |> again:  what would it take to make Lisp into a contender?  Maybe we
   |> can do something about it given that corporate America is finally
   |> waking up to the fact that the COBOL era has ended and the successor
   |> language is not yet identified.

   I can offer several reasons why Lisp is not catching up.

   1. Public choice.  Choosing a programming language for a large
   community is a bit like democratically electing a government, and
   don't tell me we do a good job at that.

   2. Most people don't like math.  Lisp self-reflecting ability
   (Lisp code is a Lisp data structure) is unmatched in other languages
   and it is one of its most powerful features.  However, using it
   requires slightly more abstract thinking than most people are
   comfortable with.

Abstract thinking is painful, if not impossible for many people; there
was an article about this in Newsweek not too long ago.  Some consider
the evolution of a person's editor-of-choice as a parallel metaphor,
i.e., C -> Lisp as Vi -> Emacs.  I personally think it's because Lisp
demands too much conceptual homework to be appreciated in short order.
Also (for reasons I don't understand), the paren's tend to get in the
way at first until a suitable editor is in place.  All the issues have
been beaten to death, though I have no doubt that if some giant with
$$ (MicroSloth?) decided to market (shove) a Microsoft Lisp down the
throats of the many, all the so called "obstacles" would melt away,
i.e., Visual Basic or Visual Dylan could easily be Visual Lisp.

   I suspect, however, that Lisp will make considerable gains
   in the near future, thanks largely to Scheme (see the recent
   GNU efforts around GUILE).  ---Luigi

I'm an engineer of 17 years experience.  Engineers are Fortran, Mathcad,
spreadsheet, C types for the most part.  Me too.  I had heard of Lisp in an
Artificial Intelligence context.  But as for applying AI to my problems at
work, the conventional wisdom is buy an expert system shell, or get a
neural network package (depending on the problem).  Neither has much to do
with Lisp anymore.

I recently took several courses in Computer Science.  Included was a Lisp
course, (Scheme).  I saw some interesting and powerful things.  But sort of
hated it -- all they did was talk about recursion and being clever.

Then Mathematica was introduced in a course.  It has most of the Lisp
features -- data = code = date, a list structure (so one can create
whatever data structures one wants on the fly), anonymous functions, etc.  
Plus it has "pattern-matching" which I think is borrowed from Prolog.  And
one can also write in the C procedural style.  

Anyway, the syntax of Mathematica was a lot easier to read.  I also did
some Lisp - like things in Mathematica, and it helped a lot to clear the
cobwebs I had when taking the Lisp course.  

Now I appreciate the easy exploratory nature of Mathematica and Lisp.  I
want to tell my fellow engineers that its not just an "AI" language, but
essentially a exploratory language for rapidly prototyping ideas for new
algorithms to solve engineering problems.  

|   I recently took several courses in Computer Science.  Included was a
|   Lisp course, (Scheme).  I saw some interesting and powerful things.
|   But sort of hated it -- all they did was talk about recursion and being
|   clever.

teaching Lisp without being at least a little smug about its obvious
superiority requires very mature teachers.  the relative lack of such
teachers may contribute to the lack of interest in Lisp for the regular
programming tasks.  the programming world _did_ take a wrong turn somewhere
when it can regard Perl and C++ as improvements on anything, and managing
_not_ to point this out to an audience that is likely to have used both of
them for practical purposes takes some discipline.

moreover, I think programming is perceived as "dirty", precisely because of
languages like Perl and C++, so when Lisp is marketed as clean, elegant,
simple, people who think they are experienced will think it's so much
marketingese and baseless hype, and start out with an attitude of "oh,
yeah?  prove it to me!", of course finding openings for a rebuttal.

I'm vacillating between CLOS and Smalltalk, in order to generate
program-writing programs and tools. The lack of a real toolset capable of
being extended and with sufficient power for real work is killing our ability
to deliver good code rapidly. C and C++ require tremendous time investments
to generate commercial quality (you can see that, because a lot of C/C++ code
isn't worth the effort of reading and won't be maintable).

I _like_ C++. I think it serves very well for many things where C would be
the obvious choice, such as writing communications drivers, data conversion,
etc. However, on very large applications, the lack of real tools and
environments immediately begins to show. Also, it is not a good choice for
expirementing with solutions. Too much up-front work is needed to "play" with
potential solutions.

I'm not dumping C++ or C for another good reason--I need to port to
machines like AS/400 and MVS, AIX, and HPUX. Having ANSII C compiler support
on those platforms means I can write code that is portable and fully
compiled. However, nobody should have to _write_ C code--we use Cfront to
generate C code from C++, and it shouldn't be rocket science to write tools
that generate C and C++ as needed, which in turn feed the Cfront.

This mixing of tools seems more appropriate than fighting over language
merits. We use VB for MS Windows screen-painting...why try to code that in
C++ with MFC or Borland's OWL? We use Oracle, Sybase, and DB/2 for database
managers--nobody would propose we roll our own RDBMS.

I'd like for us to develop tools that write and verify code, manage versions,
and manage a repository of code including design documentation and test
suites.

That is what I think Lisp would be very well suited for--creating objects
that can be stored in a repository, and which are used to specify clearly the
problem to be solved. The result of stringing these objects together is to
generate source code that is then cross-compiled for operating on Unix,
MS-DOS/Windows, MVS, OS/400, AIX, and HPUX.

Of course, the objects should be interpretable for prototyping and explorative
programming. It would be nice if the environment let the program be run
forward and backward, with code changes possible at run time...I have a long
wish list. :)

Does this seem like a reasonable use of CLOS from those who are using it?

Thanks for any and all advice or comments,
Otter

   ...

Neither.  There are more posts on the TCL and Perl groups because
there are more people trying to use those languages and failing to get
their programs to work.

This is partly because

1) more novice programmers attempt to use "scripting languages" such
as Perl and TCL than real programming languages

2) even professional programmers are often unable to write correct
Perl and TCL programs (I've tried Perl and found that I can only work
by modifying examples; I haven't tried TCL but people here at MIT say
that it is far worse than Perl).

    Regrettably, I suspect the latter and wonder what can be done to renew
    interest in Lisp.

Nothing.  Programmers are so cheap now for big corporations that your
question is just like asking "what can be done to improve the tools
given to janitors?"

The only thing that might renew interest in modern computer languages
(e.g., Lisp, ML, Ada) is a big pile of lawsuits by users of unreliable
software directed against vendors of unreliable software (e.g.,
Microshaft, Apple).

--

      -- Philip Greenspun

5. SGI as a company doesn't seem to care at all about Lisp.
   You can get C, Power C, C++, Delta C++, Fortran, Power Fortran, Ada 95,
   Pascal, ASM,  but _no_ Lisp from SGI.
   Result: it's very difficult to do graphics/MM work with Lisp,
   (at least with Common Lisp) [see 6].
   Of course, this has made business sense for SGI, specially when you can
   charge $$$$ for `fix and continue' and `dynamic classes' (i.e. kludges
   that might look very cool to C++ victims, but which make lispers sigh).
   Am I wrong, or the corporate attitudes of HP, Sun and Apple are
   closer to lispers' hearts?

6. The drive of Lisp vendors to get competitive for all kinds of applications
  is not as big as it should (eg: they don't seem to care very much about SMP;
  I know of only one working right now on better Motif integration;
  even FFI preprocessors are not that cool: I just want to `#include' and go!;
  lack of a "faster than C++" CLOS implementation attitude? (eg: frozen
  accessors)).
  Of course, given that they are as big money factories as C++ tool vendors,
  integration with a particular workstation platform is a tough call, w/o
  cooperation with the hardware manufacturer, I guess..

I think that as the telcos have been banned from being content providers
in the US (at least up to now), hardware manufaturers should not be
providing tools beyond the OS level (eg: development environments,
graphical toolkits aiming more to `programmer friendliness' than
hardware-specific optimizations), and OS makers should be banned from
selling applications.

Possibly.  On the other hand, it might simply be that many people are
not too keen on math.  Tell us truthfully, do you really want everyone
to be as smart as you?  :-)

: the programming world _did_ take a wrong turn somewhere
: when it can regard Perl and C++ as improvements on anything,

I admire your powers of simplification...

: and managing _not_ to point this out to an audience that is likely
: to have used both of them for practical purposes takes some discipline.

You've inadvertently hit the nail on the head.  Most ordinary folks feel
that abstraction just gets in the way of their getting practical work done.

I'd say that again, but it'd probably just land on top the first one.

: moreover, I think programming is perceived as "dirty", precisely because of
: languages like Perl and C++, so when Lisp is marketed as clean, elegant,
: simple, people who think they are experienced will think it's so much
: marketingese and baseless hype, and start out with an attitude of "oh,
: yeah?  prove it to me!", of course finding openings for a rebuttal.

I realize that Lisp is rather timeless, but there seems to be a bit of
chronological inversion in this analysis.  Lisp was there long before
Perl and C++.  Moreover (ain't that a great word for sounding scientific
with?), programming was regarded as "dirty" long before Perl and C++.
Furthermore, many honorable professions regard dirt as a badge of honor.

I can't speak for C++, but Perl is unabashedly blue-collar.  Maybe I
should go out and buy me a pickup truck.

: sufficiently advanced political correctness is indistinguishable from sarcasm

Oh, gee, I thought you were being serious.  Nevermind...

Okay, there's gotta be a reason for that.  I'd suggest the explanation
is going to be more psychological than mathematical.

: 2) even professional programmers are often unable to write correct
: Perl and TCL programs (I've tried Perl and found that I can only work
: by modifying examples; I haven't tried TCL but people here at MIT say
: that it is far worse than Perl).

This mostly just proves what we already know:  Programmers are almost as
good at reading documentation as they are at writing it.

Or are you suggesting that Lisp needs no documentation?

:     Regrettably, I suspect the latter and wonder what can be done to renew
:     interest in Lisp.
:
: Nothing.  Programmers are so cheap now for big corporations that your
: question is just like asking "what can be done to improve the tools
: given to janitors?"

Precisely.  Janitors are not usually considered to be members of the elite.
Especially by the elite.

: The only thing that might renew interest in modern computer languages
: (e.g., Lisp, ML, Ada) is a big pile of lawsuits by users of unreliable
: software directed against vendors of unreliable software (e.g.,
: Microshaft, Apple).

So sue us.  :-)

I guess the cycle should be some thing like:

load/define FFI
load/define lisp code
shake FFI
link foreign modules

PS: BTW, there's a NOT missing in the obvious place of that article..

True enough, but I was just trying to answer the question posed in the
subject line.  The trouble with ordinary folks is there's so many of 'em.
When you ignore a majority of the people, you shouldn't be surprised when
a majority of the people ignore you.

I suppose the not-so-serious response would be that creating work is good
for keeping the unemployment figures down.  But that's pretty abstract...

Because Smalltalk vendors have been promoting Smalltalk as a
productive tool in the MIS/Client-Server world. And they have been
relatively successful: Smalltalk is growing in that world more
rapidly than C++.

The Lisp world has many more stereotypes to overcome and noone
leading the charge. The battle is all but over. Franz is making
some amount of effort, by emphasizing objects rather than Lisp
in its Windows product.

I have been using Smalltalk for over a year now, after using CommonLisp
and Scheme as my languages of choice for ten years.

(Of choice: I don't always get to
choose and so use C++ most of all.)

It is really a subset of Lisp with a different syntax, but it is
not-too-surprisingly effective. Especially compared to C++.