From: Bill Hunter
Subject: Why is Lisp inactive compared to Perl et al?
Date: 
Message-ID: <517cb$d2920.d3@cat.bbsr.edu>
(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.

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!

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.

From: Seth LaForge
Subject: Re: Why is Lisp inactive compared to Perl et al?
Date: 
Message-ID: <3o3q43$ck1@gap.cco.caltech.edu>
In article <··············@cat.bbsr.edu>,  <·······@cat.bbsr.edu> wrote:
>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.

Check out Dylan (news:comp.lang.dylan; http://www.cambridge.apple.com).
It's a new language that Apple is developing to do many of the things
that C++ is used for these days.  It was mainly based Scheme and
Common Lisp, and adopts many of the best features of both, as well as
making an emphasis on reasonable code generation.  It is dynamically
typed, but the programmer can specify types to get the efficiency of
static typing.  Unfortunately Apple switched from a lispy syntax to a
yucky Algol syntax, but it looks like most implementations will support
both (I hope so, anyway).  The language is being created by Apple, but
any implementor may implement the language and use the name Dylan if
the implementation passes a compatibility suite.

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

Seth
From: Erik Naggum
Subject: Re: Why is Lisp inactive compared to Perl et al?
Date: 
Message-ID: <19950501T172746Z.enag@naggum.no>
[Bill Hunter]

|   (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?

#<Erik>
--
sufficiently advanced political correctness is indistinguishable from sarcasm
From: Luigi Semenzato
Subject: Re: Why is Lisp inactive compared to Perl et al?
Date: 
Message-ID: <3o5tlp$hg3@fido.asd.sgi.com>
In article <··············@cat.bbsr.edu>, <·······@cat.bbsr.edu> 
(Bill Hunter) writes:

|> 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.

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.

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
From: John P. Flanagan
Subject: Re: Why is Lisp inactive compared to Perl et al?
Date: 
Message-ID: <JPF.95May6124652@wstar>
In article <··········@fido.asd.sgi.com> ··@barracuda.engr.sgi.com (Luigi Semenzato) writes:

   In article <··············@cat.bbsr.edu>, <·······@cat.bbsr.edu> 
   (Bill Hunter) writes:

   |> 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

Good point.
--
jpf.
From: Simon Beaumont
Subject: Re: Why is Lisp inactive compared to Perl et al?
Date: 
Message-ID: <3ocrok$h9f@xenon.bt-sys.bt.co.uk>
<·······@cat.bbsr.edu> (Bill Hunter) wrote:
>
> (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,

Well it's simple Bill: all the other programmers are banging their
heads at how to do it; discussing all the problems and shortcomings
of their languages, whilst down the hall all the Lisp programmers
are into MOPs and reflection and functions and algorithms and
OI and object systems and inheritance and fuzzy logic and AI and
software engineering and knowledge engineering and tools and GUIs
and ...basically just having too much fun coding it all up: 
so they don't have time for the Usenet!

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... ;-)

Simon