Why Isn't Lisp a Mainstream Language?

35 views
Skip to first unread message

M. Bersohn

unread,
Jan 14, 1993, 12:51:40 AM1/14/93
to
Hello all you LISP experts.
I learned LISP about 25 years ago and used it intensely
for about 2 years. I had to convert the project to another
language because LISP of 1970 was simply too slow. It was
very expensive to run so slowly on a main frame.
Decades passed. Now we have cheap workstations. I've
also been hearing that LISP is now acceptably fast. SO,
like Rip Van Winkle I come back to LISP, only to find that
LISP is still not a mainstream language. This has certain
bad consequences.
1. The compilers, having fewer users per product, are more
likely to have bugs in them then compilers of Fortran,
Cobol or (is this a dirty word?) C++.
2. It's harder to find LISP programmers available for six
months or two years. In a mainstream language this is no
problem.
My question is, why after these decades, is Lisp, with
all its power and elegance, basically still confined to AI people in
Universities? What's wrong?

Bill Vrotney

unread,
Jan 14, 1993, 4:36:40 AM1/14/93
to

In article <1993Jan14....@alchemy.chem.utoronto.ca>
mber...@alchemy.chem.utoronto.ca (M. Bersohn) writes:

I used to think the answer to you question was complex, but now I think that
it is simple. I call it "C sickness". For Lisp to become mainstream it has
to be small, fast and hardened. C is mainstream. All of the technological
ingredients for Lisp to be as small, fast and hard as C are here. All that
is required at this point is desire. However, that desire is deferred by
complacency with C. C is not as good as Lisp but it is good enough. The
world has to keep rolling along. Only if people have the desire to use Lisp
as a mainstream language will it happen. Programmers will be zombies until
it does.
--
Bill Vrotney
BAH/Advanced Decision Systems

Tim Larkin

unread,
Jan 14, 1993, 9:29:09 AM1/14/93
to
In article <1993Jan14....@alchemy.chem.utoronto.ca> M. Bersohn,

mber...@alchemy.chem.utoronto.ca writes:
> My question is, why after these decades, is Lisp, with
>all its power and elegance, basically still confined to AI people in
>Universities? What's wrong?

I believe that two difficulties have kept Lisp out of the mainstream. You
have already mentioned the first reason: for a long time to
run Lisp well required a Lisp machine, a very expensive proposition. In
fact, this remains the best way to run Lisp, but no longer such an
expensive proposition.

The second obstacle involves marketing. Lisp grew up in AI Labs, and
generally people still associate it with AI. For instance, if you examine
the marketing approach of Symbolics, you will see that they still
emphasize AI, even though the history of the company amply demonstrates
that this strategy loses big. It loses because no one does AI outside of
a few AI labs! People reason that if their problem doesn't involve AI,
then they can't benefit from Lisp. Nothing could be further from the
truth. We have been using Lisp machine technology for 6 years in the
domain of continuous systems simulation. Although Flavors and Genera form
the
foundation of our work, we employ no techniques that would be recognized
as AI. Yet we could never have accomplished what we did in any other
operating system. It remains, I believe, the finest program
development environment you can get; it certainly makes anything I've
ever seen in Unix look pathetic.

The point is that Lisp ranks top as a general purpose programming
language. C doesn't even come close; C against Lisp looks like Bobby
Riggs playing against Billy Jean King. But until people stop thinking,
"Lisp => AI", Lisp will remain outside the mainstream.

>
Tim Larkin
Federal Nutrition Laboratory
Tower Road
Ithaca, New York
ts...@cornell.edu
607-255-7008

Christopher Ian Connolly

unread,
Jan 14, 1993, 7:45:37 PM1/14/93
to
In article <1993Jan14.0...@ads.com> bvro...@ADS.COM (Bill Vrotney) writes:
>it is simple. I call it "C sickness". For Lisp to become mainstream it has
>to be small, fast and hardened. C is mainstream. All of the technological
>ingredients for Lisp to be as small, fast and hard as C are here.

It also helps that for the longest time, C was "free" with every Un*x
system. I think that factor added immensely to both the C programmer
pool and to the C complacency you mentioned.

Christopher Ian Connolly conn...@cs.umass.edu
Laboratory for Perceptual Robotics wa2ifi
University of Massachusetts at Amherst Amherst, MA 01003

John Doner

unread,
Jan 18, 1993, 11:11:38 AM1/18/93
to
In article <1993Jan14....@alchemy.chem.utoronto.ca>, mber...@alchemy.chem.utoronto.ca (M. Bersohn) writes:
|> My question is, why after these decades, is Lisp, with
|> all its power and elegance, basically still confined to AI people in
|> Universities? What's wrong?

I think syntax and readability have a lot to do with it. Functional
notation puts off many people; they find it natural for short
expressions, but confusing for larger ones. Notation is extremely
important in mathematical communication, and the usual conventions of
infix operators, omitting parentheses, operations indicated by position
(superscripts for exponentiation, juxtaposition for multiplication),
and no doubt others, were introduced for good reasons and are of great
value. I have experienced many occasions where some proof was praised as
elegant, a significant improvement, etc., and where the key step was
devising a better notation. Lisp notation is simple and provides a
clear semantics, but for these very reasons is unable to provide much
syntactic flexibility or "information-hiding" (sweeping necessary but
picayune details into the background so they don't obscure the main
points).

Of course, C is almost as good for producing unreadable programs as APL,
and in the hands of a skilled obfuscator, can match the worst that Lisp
can do. But I do think that people's first impression when confronted
with some moderately complex textbook example programs will be that C is
more readable than Lisp.


John Doner
Math. Dept., UCSB

Scott McKay

unread,
Jan 18, 1993, 11:48:06 AM1/18/93
to

Date: Mon, 18 Jan 1993 11:11 EST
From: John Doner <do...@aero.org>

In article <1993Jan14....@alchemy.chem.utoronto.ca>, mber...@alchemy.chem.utoronto.ca (M. Bersohn) writes:
|> My question is, why after these decades, is Lisp, with
|> all its power and elegance, basically still confined to AI people in
|> Universities? What's wrong?

I think syntax and readability have a lot to do with it. Functional
notation puts off many people; they find it natural for short
expressions, but confusing for larger ones. Notation is extremely
important in mathematical communication, and the usual conventions of
infix operators, omitting parentheses, operations indicated by position
(superscripts for exponentiation, juxtaposition for multiplication),
and no doubt others, were introduced for good reasons and are of great
value. I have experienced many occasions where some proof was praised as
elegant, a significant improvement, etc., and where the key step was
devising a better notation. Lisp notation is simple and provides a
clear semantics, but for these very reasons is unable to provide much
syntactic flexibility or "information-hiding" (sweeping necessary but
picayune details into the background so they don't obscure the main
points).

Surely you jest. Lisp macros provide an extremely powerful tool for
syntaxtic flexibility, extensibility, and information hiding. Nothing
in C (or just about any other language) even comes close to this.

Of course, C is almost as good for producing unreadable programs as APL,
and in the hands of a skilled obfuscator, can match the worst that Lisp
can do. But I do think that people's first impression when confronted
with some moderately complex textbook example programs will be that C is
more readable than Lisp.

Funny, the following looks OK to me:

(with-database (db "employees")
(with-transaction (db)
(for-each ((e employee) (:where (> (employee-salary) salary)))
... do something ...)))

Well, I guess it could be better -- I really would rather have this:

(defmacro map-over-employees-exceeding-salary ((database salary) &body body)
`(with-database (db ,database)
(with-transaction (db)
(for-each ((e employee) (:where (> (employee-salary) ,salary)))
,@body))))

and then use this:

(map-over-employees-exceeding-salary ("employees" 50000.0)
... do something ...)

I doubt that many non-Lisp programmers can so easily extend their
language to include the new MAP-OVER-EMPLOYEES-EXCEEDING-SALARY form.

Wayne Green

unread,
Jan 18, 1993, 2:42:16 PM1/18/93
to
The students that I come into contact with hit the nail on the head
the other day when asked this question. There is no "Borland Turbo
Lisp Compiler" for the IBM PC computer, as "God intended it to
be" (640K or less). Some bright folks should develop a free
Lisp compiler and give it away. They could develop an aftermarket
book that would serve to generate royalties and just rewards for
that effort.

Languages are popular due to the base of popular support, born
by students and hobbiest. Look at the tremendous impact Pascal
received with the virtually free P-Code compiler - its transformation
into a Hobbiest tool on CPM systems. C was a late commer rising
to popularity with the introduction of an affordable Lattice
compiler. I mention the Turbo Prolog tools too. Affordable Prolog
with a usable user interface.

Almost all Lispers that I am in casual contact with know about
Xlisp by David Michael Betz, but really want a compiler.

I feel that before Lisp becomes a real tool in the real world
it must pass the rights of initiation of being a fairly real
tool in the hobbist market place. How about it Academia? Give
us a freebie and write us a book.

--Wayne

--

Wayne Green NCAR (National Center for Atmospheric Research)
FL2-1042 (303) 497-8540 FAX (303) 497-8520
P.O. Box 3000, Boulder Colorado, 80307-3000 wgr...@ncar.ucar.edu

Martin Cracauer

unread,
Jan 19, 1993, 7:29:52 AM1/19/93
to
do...@Aero.org (John Doner) writes:

>In article <1993Jan14....@alchemy.chem.utoronto.ca>, mber...@alchemy.chem.utoronto.ca (M. Bersohn) writes:
>|> My question is, why after these decades, is Lisp, with
>|> all its power and elegance, basically still confined to AI people in
>|> Universities? What's wrong?

>I think syntax and readability have a lot to do with it. Functional
>notation puts off many people; they find it natural for short
>expressions, but confusing for larger ones. Notation is extremely
>important in mathematical communication, and the usual conventions of
>infix operators, omitting parentheses, operations indicated by position
>(superscripts for exponentiation, juxtaposition for multiplication),
>and no doubt others, were introduced for good reasons and are of great
>value. I have experienced many occasions where some proof was praised as
>elegant, a significant improvement, etc., and where the key step was
>devising a better notation. Lisp notation is simple and provides a
>clear semantics, but for these very reasons is unable to provide much
>syntactic flexibility or "information-hiding" (sweeping necessary but
>picayune details into the background so they don't obscure the main
>points).

I wonder, if it is possible, to change the synatx of LISP without
loosing it's advantages.

From the dylan-faq:
> * Is Apple planning to specify an alternate syntax for Dylan?

> Yes. We recognize that many people prefer an algebraic syntax, and
> we plan to create and document such a syntax for Dylan.

How will they do that?

--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <crac...@wavehh.hanse.de>, WAVEDATA, Norderstedt, Germany

John Doner

unread,
Jan 18, 1993, 4:42:39 PM1/18/93
to
In article <1993Jan18.1...@ncar.ucar.edu>, wgr...@eckhart.scd.ucar.edu (Wayne Green) writes:
|> I feel that before Lisp becomes a real tool in the real world
|> it must pass the rights of initiation of being a fairly real
|> tool in the hobbist market place. How about it Academia? Give
|> us a freebie and write us a book.

How about Gambit Scheme? MacGambit is free, and you get all the source code.
O.k., it isn't Common Lisp, but it is a Lisp dialect, and probably more suited
to hobbyist needs anyway.

John Doner
Math. Dept., UCSB

do...@math.ucsb.edu

Tom Pole

unread,
Jan 19, 1993, 12:55:32 PM1/19/93
to

Concerning "Turbo Lisp", there are a couple of near Lisps's (subsets
of Common Lisp) that are available for PC's

THIS IS NOT A REVIEW OF THESE PRODUCTS, JUST A POINTER FOR THOSE
WHO MIGHT WANT TO FIND OUT MORE ABOUT THEM ON THEIR OWN.

Software Engineer (PC, Windows 3.1)
contact: Raindrop Software email: 70632...@compuserve.com
around $350 retail I believe, BIG educational discount available

Star Saphire Lisp (PC)
contact: Sapiens Software phone:(408) 425 0905
around $100 retail I believe, I think an educatinal site license
or some such is available.

Also there is a Full Common Lisp available from Franz called
PC\CL (PC, Windows 3.1)
$595 retail I think, haven't discussed educational pricing with them
contact: Franz Inc. phone: (510) 548 3600

A year or so ago there was a comparison of Lisps's in AI/Expert which
was a godd source of info at the time, but the PC Lisp market
has really changed, and matured in the last year or two. Also, Software
Engineer was not in that review, and PC\CL wasn't available yet.

If you really want to know about the latest news in the Lisp
development world, come to the Lisp User's and Vendor's Conference
(LUV-93) later this year. FOr information, contact:

LUV-93
c/o An Event to Remember
P.O. Box 294
Malvern, PA 19355-0294

(215) 651-2990

76470...@compuserve.com


Yes, that last part was the commercial,

Thomas
--

Thomas Pole

k p c

unread,
Jan 19, 1993, 3:18:05 PM1/19/93
to
In article <1jekrq...@news.aero.org> do...@Aero.org (John Doner) writes:

I think syntax and readability have a lot to do with it.

surely it wouldn't be difficult to include in the cl standard an
"infix" or "math" form, approximately as follows. then you'd have the
best of both worlds, wouldn't you?

(infix "2 + 3x * x^123 / (6y + sin(z))")

lisp can also use a good pattern matching facility and a little speed
and memory paring so that people are not tempted by perl, don't you
think?

it's scandalous that lisp languishes while horrible, horrible
languages thrive. it gives the lie to such notions as creativity and
competence in the wider computer field that this phenomenon is not
limited to rare classes of applications.
--
i'm open to comparing research career notes with other cogsci/cogneuro people.

hume smith

unread,
Jan 19, 1993, 5:01:54 PM1/19/93
to

surely it wouldn't be difficult to include in the cl standard an
"infix" or "math" form, approximately as follows. then you'd have the
best of both worlds, wouldn't you?

(infix "2 + 3x * x^123 / (6y + sin(z))")

lisp can also use a good pattern matching facility and a little speed
and memory paring so that people are not tempted by perl, don't you
think?

i doubt it should go into the standard... but i think it would be easy enough
to take one of the yacc sort of programs in the lisp resource archive and add
something like lex to it and make something that creates new readmacros, to
read whatever will fit the lex-yacc model. have several by indexing them
to some symbol, then you could say things like

#!infix( 2 + 3*x^123 / (6*y + sin(z)) )

which still looks a little horrid, i suppose.

i've been thinking about doing this for a while, but i don't have the time
for neat tinkering like that :-(
--
Hume Smith My name is little Bongo
hume....@acadiau.ca I sing my little song-go
emc...@bnr.ca Rhymes are hard to think of
Except for made-up words like "flong-go"

Arun Welch

unread,
Jan 19, 1993, 8:37:09 PM1/19/93
to
Tom missed one in his list of PC Lisps:

Medley (PC)
Contact: Venue email: aisupp...@envos.xerox.com
I think the price is $495, but I'm not positive, so check.
Phone: (800)-228-5325. Binary-compatible on all architectures,
from PC to Alpha...

...arun
ps. Yeah, I'm biased.
----------------------------------------------------------------------------
Arun Welch
Lisp Systems Programmer, Lab for AI Research, Ohio State University
we...@cis.ohio-state.edu

Tim Larkin

unread,
Jan 20, 1993, 10:48:53 AM1/20/93
to
In article <KPC.93Ja...@zog.arc.nasa.gov> k p c,

k...@pluto.arc.nasa.gov writes:
>surely it wouldn't be difficult to include in the cl standard an
>"infix" or "math" form....

Symbolics Common Lisp already has such a feature, a reader macro defined
so that you can write #@x + y + sin(z)@, where I have substituted @ for
the actual dispatching character, escape. The major difficulty it poses
for me arises from the parsing of symbol names that include the hyphen.
The macro wants to interpret foo-bar as (- foo bar), so you need to write
foo\-bar.

Nonetheless, I rarely use this, unless transcribing a highly complex,
infix
formula. Prefix notation takes a bit of getting used to, but it possesses
its own charm.

Larry Wall

unread,
Jan 20, 1993, 1:12:44 PM1/20/93
to
In article <KPC.93Ja...@zog.arc.nasa.gov> k...@ptolemy.arc.nasa.gov writes:

: In article <1jekrq...@news.aero.org> do...@Aero.org (John Doner) writes:
:
: I think syntax and readability have a lot to do with it.
:
: surely it wouldn't be difficult to include in the cl standard an
: "infix" or "math" form, approximately as follows. then you'd have the
: best of both worlds, wouldn't you?
:
: (infix "2 + 3x * x^123 / (6y + sin(z))")
:
: lisp can also use a good pattern matching facility and a little speed
: and memory paring so that people are not tempted by perl, don't you
: think?

I think you're trying to put a bandaid on a bleeding stump, but then
I'm known to be prejudiced in the matter.

Anyway, on to bearding the lion...

: it's scandalous that lisp languishes while horrible, horrible


: languages thrive. it gives the lie to such notions as creativity and
: competence in the wider computer field that this phenomenon is not
: limited to rare classes of applications.

The obvious answer is almost TOO obvious. People prefer "horrible" languages.

I believe in the waterbed theory of linguistics. If you push down
here, it pops up there. The design of Lisp pushed down so hard on the
morphology that it bulges out everywhere else. Lisp is your classical
Turing Tarpit. If expressivity only measures what's possible, Lisp is
wonderful. If it measures what's easy to say and understand, Lisp gets
a big yawn from most folks. You don't take your dinner every night and
put it in a blender. Why should I program in a language that has the
same bland taste all the way through? I want my salad to taste like
salad, my carrots to taste like carrots, and my turkeyburger to taste
like veal cordon bleu. :-)

Please reply in Lisp, not English. It's so much more expressive...

Larry Wall
lw...@netlabs.com

Scott McKay

unread,
Jan 20, 1993, 2:10:53 PM1/20/93
to
Date: Wed, 20 Jan 1993 13:12 EST
From: Larry Wall <lw...@netlabs.com>

The obvious answer is almost TOO obvious. People prefer "horrible" languages.

I believe in the waterbed theory of linguistics. If you push down
here, it pops up there. The design of Lisp pushed down so hard on the
morphology that it bulges out everywhere else. Lisp is your classical
Turing Tarpit. If expressivity only measures what's possible, Lisp is
wonderful. If it measures what's easy to say and understand, Lisp gets
a big yawn from most folks. You don't take your dinner every night and
put it in a blender. Why should I program in a language that has the
same bland taste all the way through? I want my salad to taste like
salad, my carrots to taste like carrots, and my turkeyburger to taste
like veal cordon bleu. :-)

I cannot decide if your analogies are false since I cannot make heads
or tails of them. In what way is Lisp "bland ... all the way
through"? How does Lisp's expressiveness (which I believe measures
"easy to say and understand") "[get] a big yawn"? Is it because Lisp
is so expressive, that it is boring? Are you saying that most other
languages, because they are so horrible and so inexpressive, are not
boring because they elicit anger and frustration, whereas Lisp does
not elicit those emotions? Are you saying that you think that the
true challenge in programming is the actual struggling with the
language, rather than the addressing the deeper issues (such as, what
it is you are trying to do)? In what way does Lisp "push down so
hard" on morphology? Where's the "tar pit", and what languages do
better? (I can think of some languages that do better in some areas,
but none that, taken as a whole, do better for most purposes).

I can't even decide if you are serious or not. I guess that all of
your handwaving means that you must be making a joke. In that case,
I guess I am too dense to get the joke.

Lou Steinberg

unread,
Jan 20, 1993, 5:01:29 PM1/20/93
to
> In article <KPC.93Ja...@zog.arc.nasa.gov> k...@pluto.arc.nasa.gov (k p c) writes:
>
> surely it wouldn't be difficult to include in the cl standard an
> "infix" or "math" form, approximately as follows. then you'd have the
> best of both worlds, wouldn't you?

There have been many of these "surface syntaxes" for lisp. I used one
(MLISP, I think) for a while back in '73 or so when I was learning
lisp. But I soon dropped it in favor of the normal lisp. The main
reason was that, using the interactive debugger, you saw the
"internal" form (the normal lispish prefix notation) anyway, and
the mental cost of having to deal with two syntaxes, especially
with the same code in two syntaxes, was much worse than the mental
cost of writing in prefix syntax to start with.

Maybe we need a "training wheels" syntax to entice people into lisp,
but I doubt that many will stay with that syntax for long.
--
Lou Steinberg

uucp: {pretty much any major site}!rutgers!aramis.rutgers.edu!lou
internet: l...@cs.rutgers.edu

Scot Dyer

unread,
Jan 20, 1993, 4:32:52 PM1/20/93
to
;;; [stuff deleted]
;;;
;;; (infix "2 + 3x * x^123 / (6y + sin(z))")
;;;
;;; [stuff deleted]
;;;
;;; i doubt it should go into the standard... but i think it would be easy

;;; enough to take one of the yacc sort of programs in the lisp resource
;;; archive and add something like lex to it and make something that
;;; creates new readmacros, to read whatever will fit the lex-yacc model.
;;; have several by indexing them to some symbol, then you could say things
;;; like
;;;
;;; #!infix( 2 + 3*x^123 / (6*y + sin(z)) )
;;;
;;; which still looks a little horrid, i suppose.
;;;
;;; i've been thinking about doing this for a while, but i don't have the
;;; time for neat tinkering like that :-(

Interlisp had a reader ("CLISP") that accepted an infix notation.

I think the lack of exceptance of LISP as a language goes all the way back to
the first LISPs, which _were_ pigs. Or at least _then_ they were, but this
was during the days of what, FORTRAN II when a machine having more than 64 Kb
was a big deal? LISP was _way_ ahead of its time, and it's reputation has
yet to be shaken.

Computer Science is even more prone to vogue and fashion than
psychology, so what's popular really doesn't say that much about what's
good and right. I doubt this will ever change. :(

Living with it,
Scot

+------------------------+-----------------------------------------------+
|Scot Dyer_Rivenburgh | "Land of song," said the warrior bard, |
|dy...@eagle.sharebase.com| "Though all the world betrays thee, |
+------------------------+ One sword, at least, thy rights shall guard, |
|(He's right, you know.) | One faithful harp shall praise thee." |
+------------------------+-----------------------------------------------+

P.S. Anybody out there know of SF Bay Area job openings using a LISP? I
recognise that this is a bit cheesy, but I'd love to hear about them...

k p c

unread,
Jan 20, 1993, 7:22:53 PM1/20/93
to
i agree about source level vs. expanded-macro level debugging, but
even the wonderful cl loop facility has that problem under allegro.
wish it were fixed.

but if we are willing to stray from simple syntax for loop and format,
don't you think we might want to include a basic infix evaluator so as
to answer the objections to lisp from the math quarter? the same goes
for pattern matching. (nregex helps.)

especially if it's close to a matter of survival, as some claim....

Arun Welch

unread,
Jan 20, 1993, 9:45:22 PM1/20/93
to

Interlisp had a reader ("CLISP") that accepted an infix notation.

Ahem. That should be "has" a reader... Some of us are still using
Interlisp-D, and it's still a supported product.

...arun
Info-110...@cis.ohio-state.edu

Strong datatypes for weak minds.

unread,
Jan 20, 1993, 9:42:04 PM1/20/93
to

In <1993Jan14.0...@ads.com>, bvro...@ADS.COM (Bill Vrotney) writes...

; I used to think the answer to you question was complex, but now I
; think that it is simple. I call it "C sickness". For Lisp to


; become mainstream it has to be small, fast and hardened.

Not. The mainstream is not controlled by computer scientists, but by
mass market dweebs. C compilers are becoming a fat, bloated miasmas
much like the 80x86-seeking public (go install a Borland product), and
mutants like C++ aren't even ANSI/ISO standards.

Today form is more important than function, marketing is king, and
vendors are catering to that mass market.

Perhaps Scheme and Dylan are the last, best hope to dent the mainstream.

Regards,
rcs

Strong datatypes for weak minds.

unread,
Jan 20, 1993, 9:56:49 PM1/20/93
to

In <1993Jan18.1...@ncar.ucar.edu>, wgr...@eckhart.scd.ucar.edu
(Wayne Green) writes...

; ...rising popularity with the introduction of an affordable

; Lattice compiler. I mention the Turbo Prolog tools too.
; Affordable Prolog with a usable user interface.

Affordable... and failed in the market place !

Regards,
rcs

ROBERTO AVANZI

unread,
Jan 21, 1993, 4:45:25 AM1/21/93
to
In article <1993Jan20....@netlabs.com> lw...@netlabs.com (Larry Wall) writes:
>
>Please reply in Lisp, not English. It's so much more expressive...
>
>Larry Wall
>lw...@netlabs.com

: (GETPROP 'LISP 'BEAUTY)
"MARVELOUS"

: (GETPROP 'PERL 'USEFULNESS)
"GREAT"

Cheers
Roberto Avanzi

Bill Birch

unread,
Jan 21, 1993, 11:07:02 AM1/21/93
to
But surely Lisp IS a mainstream language! It has survived the test
of time. Whatever happened to ALGOL, et. al.? Just because a
language is not used by Joe Programmer doesn't mean that
it is dead. After all, Joe Programmer probably used Lisp
at College. He may use Lisp concepts in his 'C' programs.

By analogy, Buddy Holly is not a "mainstream" artist these
days, but his influence on other artists is there.

Bill
--
Bill Birch | B.B...@uk03.bull.co.uk
Bull Info. Sys. Ltd. | Bull Tel: 773 4770
Maxted Road, | Bull Mail: HM14 UK03
Hemel Hempstead, | Tel: +44 442 884770
HERTS, HP2 7DZ, U.K. | Fax: +44 442 884570
Aviate, Navigate, Communicate...

Tony Davie

unread,
Jan 21, 1993, 11:00:33 AM1/21/93
to
I personally like a functional language with more syntax than LISP.
Haskell is my favourite but Miranda and ml are good too. The things I like
about them in particular are their pattern matching and static type checking.

But, if you like that sort of thing, LISP's main feature is that it has a
particularly simple syntax. Don't bugger around with it. If you want higher
level syntax, use a syntactically higher level language, not a bastardised
modified LISP, which isn't suited to it. It's not that sort of language.

Tony Davie

k p c

unread,
Jan 21, 1993, 2:22:20 PM1/21/93
to
i like lisp's simple syntax also.

but if adding one or two functions, each less complicated than loop
and format, answers 90% of joe programmer's objections, and if that
will help lisp survive, imho it's worth the cost. it's not as if we'd
be changing the syntax of the language itself.

Ted Dunning

unread,
Jan 21, 1993, 2:56:42 PM1/21/93
to

In article <24...@sousa.tay.dec.com> sec...@msdsws.enet.dec.com

(Strong datatypes for weak minds.) writes:


Perhaps Scheme and Dylan are the last, best hope to dent the
mainstream.


given the mindset of the people who effectively control the evolution
of scheme, there is absolutely no hope of scheme becoming a useable
language for mainstream programming.

i am not saying that the mindset is wrong, just that it completely
prevents the language from going in the directions needed to be a
really useable and marketable language.

Ted Dunning

unread,
Jan 21, 1993, 2:56:53 PM1/21/93
to

In article <24...@sousa.tay.dec.com> sec...@msdsws.enet.dec.com
(Strong datatypes for weak minds.) writes:


Perhaps Scheme and Dylan are the last, best hope to dent the
mainstream.

Larry Wall

unread,
Jan 21, 1993, 6:06:42 PM1/21/93
to
In article <1993012019...@SUMMER.SCRC.Symbolics.COM> S...@stony-brook.scrc.symbolics.com (Scott McKay) writes:
: I cannot decide if your analogies are false since I cannot make heads
: or tails of them.

You should try to make CARs and CDRs of them instead.

: In what way is Lisp "bland ... all the way through"?

There's little visual distinctiveness to distinguish mentally
distinctive constructs.

: How does Lisp's expressiveness (which I believe measures "easy to say


: and understand") "[get] a big yawn"? Is it because Lisp is so expressive,
: that it is boring?

No, I'm saying that Lisp is only expressive by one rather cerebral kind
of measurement, which neglects many human factors related to how we
think, perceive and talk. And that this is the primary reason people
avoid Lisp.

: Are you saying that most other languages, because they are so


: horrible and so inexpressive, are not boring because they elicit anger
: and frustration, whereas Lisp does not elicit those emotions?

I don't believe that the absence of boredom implies the presence of
anger and frustration. All these states of being are in opposition to
creative excitement.

: Are you saying that you think that the true challenge in programming


: is the actual struggling with the language, rather than the addressing
: the deeper issues (such as, what it is you are trying to do)?

I haven't noticed people struggling that much less with Lisp than with
most other languages. Admittedly, nroff is a bit tougher, unless
you're just trying to do text processing... :-)

: In what way does Lisp "push down so hard" on morphology?

One form to rule them all,
One form to find them,
One form to bring them all
And in the darkness bind them.
In the land of machinery, where the symbols lie.

Essentially, Lisp assumes that humans like to write programs the same
way the machines like to execute them, and so conflates the human
representation with the machine representation. True, there are Lisp
compilers, but the "ideal" is still that the machine and the programmer
are interpreting the exact, same, one-size-fits-all data structure.

: Where's the "tar pit", and what languages do better? (I can think of


: some languages that do better in some areas, but none that, taken as a
: whole, do better for most purposes).

That's precisely the point. "Beware the Turing Tarpit, where
everything is possible, and nothing is easy."

That said, I should back off a little and admit that there are a few
things that are easier in Lisp than in other languages. But your
assumption seems to be that it's better to use an all-around mediocre
language for most everything than to use each language for what it does
best. I'm just pointing out the obvious fact that most people disagree
with that assumption nowadays, and that I suspect that this is the
answer to the question posed in the subject line of this thread.

: I can't even decide if you are serious or not. I guess that all of


: your handwaving means that you must be making a joke. In that case,
: I guess I am too dense to get the joke.

Never assume, just because I'm making a joke, that I'm not also quite serious.

Larry Wall
lw...@netlabs.com

William J. Bouma

unread,
Jan 21, 1993, 7:42:21 PM1/21/93
to

In article <1993Jan21....@uk03.bull.co.uk>, bbi...@hemel.bull.co.uk (Bill Birch) writes:
|> But surely Lisp IS a mainstream language! It has survived the test
|> of time. Whatever happened to ALGOL, et. al.? Just because a
|> language is not used by Joe Programmer doesn't mean that
|> it is dead. After all, Joe Programmer probably used Lisp
|> at College. He may use Lisp concepts in his 'C' programs.

I agree with this. From where I sit (ie. university environment)
Lisp looks pretty popular. It is being taught. Even though we
disposed of our Lisp machines, people still program in CL. People
use Lisp to program Emacs, and use symbolic math pakages such as
MACSYMA that are written on top of Lisp.

Other posts in this thread speculate that Lisp is less popular than
C because of some programming issue such as prefix vs infix math
notation, or function call notation. I don't think it has anything
to do with coding in the languages, as the majority of those who have
programmed in both is bound to prefer Lisp. ;^)

The main reason C is preferred over Lisp is the environmental baggage
Lisp carries. If I compile a small C program I get a small standalone
binary. I type the name of that binary and it runs. If I compile a
small CL program I get a small binary, but I have to load that into
an 8Mb environment in order to run it. If I want to run a different
C program, I just type its name. If I want to run another Lisp
program I either have to reload the 8Mb, or make sure there are no
name clashes with the previous program(s) loaded in. Then, what if
I want to run programs in seperate processes?

With the prevalence of operating systems like UNIX, Lisp would be
much much more popular if it compiled small standalone binaries.
--
Bill <bo...@cs.purdue.edu>

Jim Carden

unread,
Jan 21, 1993, 8:07:19 PM1/21/93
to
In article <1993Jan21.2...@netlabs.com> lw...@netlabs.com (Larry Wall) writes:
>In article <1993012019...@SUMMER.SCRC.Symbolics.COM> S...@stony-brook.scrc.symbolics.com (Scott McKay) writes:
>: In what way is Lisp "bland ... all the way through"?
>
>There's little visual distinctiveness to distinguish mentally
>distinctive constructs.

Written by the designer of Perl. Well, Perl certainly cannot be accused of being bland.

To each his own, I guess. I cannot disagree more with almost everything Larry Wall
has written on this subject. As far as syntax goes, LISP and Perl are about as far apart
as they can be (and I hope LISP does not budge).

Pete Halverson

unread,
Jan 22, 1993, 9:52:26 AM1/22/93
to

Seconded. Every now and then you see a post that reveals a particular
viewpoint so completely alien to your own experience and beliefs that it's
pretty much impossible to address on a point by point basis. Of course, I'm
not surprised that Larry would have fairly well-thought-out views on
language design and syntax, and if Perl is any indicator, that they differ
radically from most others reading this group; it's just very difficult for
me to understand the design philosophy that these views represent.

What's more interesting is the difference this post illustrates between the
view of the problems with Lisp held by those "outside" the Lisp community
and that held by those "inside" the community. Most of the non-Lisp-users'
comments have been, almost universally, about syntax. "Lots of Idiotic
Silly Parentheses". "Lisp assumes that humans like to write programs the


same way the machines like to execute them, and so conflates the human

representation with the machine representation." And so on. And yet, if
you look at the problems the Lisp users are talking about, *nobody* brings
up syntax as a "real" issue. We talk about problems with application
delivery and deployment, confusing/redundant language features, the lack of
Genera on a Sun :-) When syntax is mentioned, it's in terms of a marketing
problem, in the same paragraph that we address the myth that Lisp is an
interpreted language where you have to shoehorn all your data structures in
to lists. All we have to do, it's claimed, is educate enough people on the
real benefits of Lisp, and they'll be so bowled over by Lisp's power that
they'll be more than willing to struggle with the syntax for a little
while. After all, it worked for *us*, didn't it?

Personally, when I'm comparing languages, syntax is way down on my list.
Sure, Ada is verbose, C seems to be more susceptible than most to
obfuscation, Perl is just plain chaotic, whatever. But much more important
to me are issues like modularity, extensibility, and semantic
expressibility. I suppose there was some initial work involved in picking
up the rhythms of Lisp syntax, but that's true with any language, and Lisp
was no more difficult than any other.

Why, then, do others make such an issue of Lisp's syntax? Partly it's our
fault, I suppose, for always trying to claim that the simplicity of it
makes it easier to learn. For one thing, it's not really that simple, once
you get beyond the Reader, and for another, some folks, like Larry, don't
seem to *like* simplicity, preferring the alleged "creative excitement" of
chaos. But, in general, why the discrepency?

Finally,

>>That said, I should back off a little and admit that there are a few
>>things that are easier in Lisp than in other languages. But your
>>assumption seems to be that it's better to use an all-around mediocre
>>language for most everything than to use each language for what it does
>>best.

Well, no, the assumption held most Lisp programmers I know, many of whom
have had substantial experience with other more chaotic languages, is that
when it comes to developing large, complex systems for which there is no
single target that can be addressed by some more focused language, Lisp
wins hands down, not just in a "few things". Very few, if any, would write
a small file utility in Lisp, any more than would attempt to build a large
application in Perl. But this has nothing to do with syntax.

Pete Halverson INET: halv...@crd.ge.com
GE Corporate R&D Center UUCP: uunet!crd.ge.com!halverson
Schenectady, NY

Scott McKay

unread,
Jan 22, 1993, 11:44:03 AM1/22/93
to
Date: Thu, 21 Jan 1993 18:06 EST
From: Larry Wall <lw...@netlabs.com>

In article <1993012019...@SUMMER.SCRC.Symbolics.COM> S...@stony-brook.scrc.symbolics.com (Scott McKay) writes:


: I cannot decide if your analogies are false since I cannot make heads
: or tails of them.

You should try to make CARs and CDRs of them instead.

I personally think CAR and CDR could have been flushed from the
language, since FIRST and REST do the exact same thing. Note, by the
way, that you have picked one of the very few things retained in Common
Lisp for historical purposes.

: In what way is Lisp "bland ... all the way through"?

There's little visual distinctiveness to distinguish mentally
distinctive constructs.

This is simply not a valid criticism. There is little visual
distinctiveness in English to distinguish mentally distinctive
constructs, and yet you do not fault English. In fact, one could argue
that "visual distinctiveness" is a principally a matter of typography.

: How does Lisp's expressiveness (which I believe measures "easy to say
: and understand") "[get] a big yawn"? Is it because Lisp is so expressive,
: that it is boring?

No, I'm saying that Lisp is only expressive by one rather cerebral kind
of measurement, which neglects many human factors related to how we
think, perceive and talk. And that this is the primary reason people
avoid Lisp.

This is still a handwave. You might be right that it is "easy to say
and understand" things in other languages, but I can equally well claim
(with support from others) that it's "easy to say and understand" things
in Lisp as well. And unlike in most other languages, if something
becomes cumbersome to say in Lisp, you can write a macro to make it easy
to say again. Since Lisp is it's own meta-language (this is what many
people erroneously refer to as "Lisp not having any syntax"), Lisp
macros are a natural thing for people to write and use. It would be
wonderful if other languages did as well, but since a truly powerful
macro facility has to, in effect, operate on the syntax tree for a
language form, things get harder.

I really think that the burden is still on you to define what you mean
by "expressiveness", and then show how your pet languages meet these
criteria, and how how Lisp does not.

: Are you saying that most other languages, because they are so
: horrible and so inexpressive, are not boring because they elicit anger
: and frustration, whereas Lisp does not elicit those emotions?

I don't believe that the absence of boredom implies the presence of
anger and frustration. All these states of being are in opposition to
creative excitement.

Yes. Boredom, anger, and frustration are all in opposition to creative
excitement. But you didn't answer the question. I personally get my
creative excitement from trying to solve new problems, not from
successfully cajoling a language into doing what I want it to do.

: Are you saying that you think that the true challenge in programming
: is the actual struggling with the language, rather than the addressing
: the deeper issues (such as, what it is you are trying to do)?

I haven't noticed people struggling that much less with Lisp than with
most other languages. Admittedly, nroff is a bit tougher, unless
you're just trying to do text processing... :-)

Perhaps it is the sort of software I do, but I emphatically do notice
people struggling more with most other languages than with Lisp. Let's
look at memory management, for instance. In most other languages, such
as C, programmers must confront the issue of memory management head on,
right away, even if they don't want to do memory management. I'm
willing to simply concede the point that, with a little practice,
"anybody" can write working memory management in C (although not without
first pointing out that, in the past year I've read two papers claiming
that around 40% of a C programmer's time is spent chasing dangling
poiinters and storage leaks). The point is that, in most other
languages, programmers must immediately tackle programming tasks that
are only incidentally related to the problem at hand.

: In what way does Lisp "push down so hard" on morphology?

One form to rule them all,
One form to find them,
One form to bring them all
And in the darkness bind them.
In the land of machinery, where the symbols lie.

Essentially, Lisp assumes that humans like to write programs the same
way the machines like to execute them, and so conflates the human
representation with the machine representation. True, there are Lisp
compilers, but the "ideal" is still that the machine and the programmer
are interpreting the exact, same, one-size-fits-all data structure.

I fail to see that Lisp makes any such assumption. What machines
directly execute mapping operators? Reduction operators? What machines
directly execute generic arithmetic, including integers, large integers,
floating point, and ratios? Hash tables? Sequences and collections?
This claim just cannot be made to stick.

If I didn't know better, I would be sure that you are talking about C/C++.

I also think you have confused what you call "machine representation"
with "parsed representation". The fact that the human-readable
representation is the same as the basic parsed representation is one of
the great sources of Lisp's power -- it allows Lisp programs to
effortlessly talk about Lisp programs.

Perhaps you think that Lisp's "one-size-fits-all data structure" is the
list, but that reflects a circa-1972 bias for the language (or maybe
even earlier).

: Where's the "tar pit", and what languages do better? (I can think of
: some languages that do better in some areas, but none that, taken as a
: whole, do better for most purposes).

That's precisely the point. "Beware the Turing Tarpit, where
everything is possible, and nothing is easy."

I'll consider myself warned, and avoid Algol-68 as much as possible.

That said, I should back off a little and admit that there are a few
things that are easier in Lisp than in other languages. But your
assumption seems to be that it's better to use an all-around mediocre
language for most everything than to use each language for what it does
best. I'm just pointing out the obvious fact that most people disagree
with that assumption nowadays, and that I suspect that this is the
answer to the question posed in the subject line of this thread.

I don't claim that Lisp is an all-around mediocre language. It's an
all-around excellent language. Sure, there are some languages that have
a few features that are better than what I can find in Lisp, but so
what? If you just want to do rule-chaining and nothing else, by all
means use Prolog. If you are writing an interrupt handler for a device,
why not use C or Bliss? If you are doing program proofs, use ML or
Haskell. And why not use Fortran for some scientific hacking? But for
general programming, I'll take Lisp nearly every time. Moral: use the
right tool for the job.

So while you may be pointing out an obvious fact that people don't want
to use an all-around mediocre language, you are just tilting at a windmill,
since I made no such assumption.

: I can't even decide if you are serious or not. I guess that all of
: your handwaving means that you must be making a joke. In that case,
: I guess I am too dense to get the joke.

Never assume, just because I'm making a joke, that I'm not also quite serious.

What makes me sad is that I know you're serious, and yet you have
entirely missed the real issues about why Lisp isn't a mainstream
language. Other messages (e.g., Pete Halverson's) under the same
subject have started to touch on the real issues.

David F. Skoll

unread,
Jan 22, 1993, 12:21:25 PM1/22/93
to
I've noticed a thread extolling the beauty of Lisp syntax. While I agree
that mostly, Lisp syntax is easy to understand and consistent, I wonder
what sort of mental disease struck the creators for the "format" function.
Take a look at all the baroque format directives in Common Lisp. I mean,
who really needs the number 394829348234982435 formatted in English words??
Just try (format t "~R~%" 394829348234982435) for fun!

--
David F. Skoll

Hal Mueller

unread,
Jan 22, 1993, 1:22:18 PM1/22/93
to
In article <dfs.727723285@noonian> d...@doe.carleton.ca (David F. Skoll) writes:
>who really needs the number 394829348234982435 formatted in English words??
>Just try (format t "~R~%" 394829348234982435) for fun!

Well, if i DID need it, I'd hate to write it! Fortran and C versions
are left as an exercise.

--
Hal Mueller If guns are outlawed, only the government
hmue...@orca.tamu.edu will have guns.

David F. Skoll

unread,
Jan 22, 1993, 1:59:41 PM1/22/93
to
In <1jpe0q...@tamsun.tamu.edu> hmue...@orca.tamu.edu (Hal Mueller)
writes:

>In article <dfs.727723285@noonian> d...@doe.carleton.ca (David F.
Skoll) writes:

>>who really needs the number 394829348234982435 formatted in English words??
>>Just try (format t "~R~%" 394829348234982435) for fun!

>Well, if i DID need it, I'd hate to write it! Fortran and C versions
>are left as an exercise.

Actually, it wouldn't be too bad in C (if you can ignore the
fixnum/bignum problems :-)) I agree that Lisp has many built-in
conveniences. Maybe too many - we have Allegro Common Lisp on our Sun
network, and the image is 11MB long. That's a huge overhead, and
anyone supporting the full Common Lisp spec probably couldn't do it in
much less.

I like Lisp. I've worked on a large CAD program, and for that, Lisp
was great. But for small-to-medium programs, I find the overhead of
Common Lisp way too high.

--
David F. Skoll

Erann Gat

unread,
Jan 22, 1993, 2:30:36 PM1/22/93
to
In article <dfs.727723285@noonian> d...@doe.carleton.ca (David F. Skoll) writes:
>I've noticed a thread extolling the beauty of Lisp syntax. While I agree
>that mostly, Lisp syntax is easy to understand and consistent, I wonder
>what sort of mental disease struck the creators for the "format" function.
>Take a look at all the baroque format directives in Common Lisp. I mean,
>who really needs the number 394829348234982435 formatted in English words??

Someone writing a program to print checks might find ~R to be quite
useful. (You seem to be complaining about two orthogonal issues, by
the way, the syntax of format strings and their functionality. The
syntax I will concede is not a model of clarity, but it is not represent-
ative of the rest of the language.)

Erann Gat
g...@aig.jpl.nasa.gov

David F. Skoll

unread,
Jan 22, 1993, 2:54:19 PM1/22/93
to
In <1jpi0s...@elroy.jpl.nasa.gov> g...@forsight2.jpl.nasa.gov (Erann
Gat) writes:

>(You seem to be complaining about two orthogonal issues, by
>the way, the syntax of format strings and their functionality.

You are right. I wrote my article hastily. But the "format" function
is representative of one aspect of Common Lisp which I believe
prevents it from becoming a "mainstream" language - Common Lisp
attempts to do almost everything, with the result that 90% of the Lisp
image is devoted to functions a small-to-medium program will never use.

And people have been arguing that Lisp is a very good general
purpose language. A function that prints English names of numbers
is a pretty special-purpose function!

--
David F. Skoll


Mark S. Riggle

unread,
Jan 22, 1993, 2:26:20 PM1/22/93
to

I think that one aspect of Lisp syntax that can be
confusing to lisp novices is that the first
position of a list is the functional call, EXCEPT
in certain forms. Like the lambda argument list,
'let', 'do' and others, including some user defined
macros.

ie. te consider the following fragments:

(let
((fred (x))
(sam (y))))

(letter
((fred (x))
(sam (y))))

So syntactically they look the same, but we all
know they are semantically vastly different, except
of course we have made a macro definition for
letter that is the same as say let or let*.

I think it actually takes quite some exposure to
Lisp before this semantic transformation is natural
and automatic to someone.

--
=============================================================
Mark Riggle [Professional Lisp Bigot]
sas...@unx.sas.com
SAS Institute Inc.,
SAS Campus Drive, Cary, NC, 27513
(919) 677-8000

hume smith

unread,
Jan 22, 1993, 3:14:58 PM1/22/93
to
this is probably the first cross-post between these two groups :-)

In article <1jpe0q...@tamsun.tamu.edu> hmue...@orca.tamu.edu (Hal Mueller) writes:

In article <dfs.727723285@noonian> d...@doe.carleton.ca (David F. Skoll) writes:
>who really needs the number 394829348234982435 formatted in English words??
>Just try (format t "~R~%" 394829348234982435) for fun!

printing cheques from the US gov't to its defence contractors? but that's mostly
in Cobol i suppose... perhaps the mexican gov't... all those pesos...

Well, if i DID need it, I'd hate to write it! Fortran and C versions
are left as an exercise.

(for alt.usage.english readers - lisp's ~R format directive, according to the
draft ANSI standard, will print an integer in one of four formats; english
cardinal (4 -> four), english ordinal (4 -> fourth), "new roman" (4 -> IV),
and "old roman" (4 -> IIII).)

i have a few questions about ~R, some of which are lisp questions, and some
english. if any appreciable discussion ensues, i should probably try to
split the thread (unravel it?) into the two groups. (i'm probably stretching
it even to start the two together.)

- the draft is silent about what to do with nonpositives, especially
for roman numerals. should the english cardinal of -1 be "minus one" or
"negative one"? (i prefer the latter - minus, to me, is the operator
not the additive inverse.) what should happen with the others?
does "zeroth" make sense to anyone other than a thermodynamicist? :-)

- which english style should BIG numbers (such as Mr. Skoll provided)
be written into? i assume, since it's the AMERICAN national standards
institute, they mean the american way - million, billion, trillion,
etc. not the english million, milliard, billion, billiard (?), etc.
or will the standard permit/expect adaption to locale, using milliard
in York and billion in New York? does the usual system locale setup stuff
even handle this kind of information?

- (definitely an alt.usage.english question) what is the progression
for very large numbers? mi-, bi-, tri-, quad-, quint-, sext-, sept-,
oct-, non-, dec-; then what? i remember something like vingintillion
in american for 1000^(20+1)...

i'm not asking idly; i hope to begin giving XLisp bignums, and would
like to provide as much of ~R as i possibly can as well, just 'cause
it's so cute! :-)

(and to Mr. Mueller: i've written such an expander in Basic; it really
isn't so bad. the three-digit cycle helps a lot.)
--
Hume Smith Honour sick and davey cris-cross
hume....@acadiau.ca McTruloff sentimie
emc...@bnr.ca A parsnip inner pair threes.

hume smith

unread,
Jan 22, 1993, 4:10:06 PM1/22/93
to
In article <dfs.727732459@kehleyr> d...@doe.carleton.ca (David F. Skoll) writes:

And people have been arguing that Lisp is a very good general
purpose language. A function that prints English names of numbers
is a pretty special-purpose function!

hmm... what makes a general purpose language? does providing lots of special
functions have anything to with it?

i think you can turn the argument around (classic usenet fashion) and say
that functions that only print numbers in digits is pretty special purpose
too. especially, functions that read and write floating point in base ten
only (my personal beef - there's no reason it can't be done in other bases!).

i think it's a nice little bonus feature. when do you ever use most of the
functions in the UNIX C libraries? isn't it handy the one time in a hundred
you need them - you can keep on truckin' instead of trying to figure out how
to patch around the hole?

k p c

unread,
Jan 22, 1993, 5:20:48 PM1/22/93
to
there are technical solutions to that problem, aren't there? i recall
there being something called presto that would eliminate parts of lisp
that weren't being used.

Carl L. Gay

unread,
Jan 22, 1993, 6:51:21 PM1/22/93
to

Newsgroups: comp.lang.lisp
From: d...@doe.carleton.ca (David F. Skoll)
Date: Fri, 22 Jan 1993 18:59:41 GMT

>>who really needs the number 394829348234982435 formatted in English words??
>>Just try (format t "~R~%" 394829348234982435) for fun!

Actually, it wouldn't be too bad in C (if you can ignore the


fixnum/bignum problems :-)) I agree that Lisp has many built-in
conveniences. Maybe too many - we have Allegro Common Lisp on our Sun
network, and the image is 11MB long. That's a huge overhead, and
anyone supporting the full Common Lisp spec probably couldn't do it in
much less.

I couldn't just let this one go by. The image for Macintosh Common
Lisp is ~1.5 MB, which includes the programming environment. (I have
no idea why the Allegro image is so big...)

Bruno Haible

unread,
Jan 22, 1993, 7:59:39 PM1/22/93
to
S...@stony-brook.scrc.symbolics.com (Scott McKay) writes:

> And why not use Fortran for some scientific hacking?

What was wrong with Maclisp's numeric code? What is wrong with Lisp compilers
that have unboxed representations for floating point numbers?

Aren't the bignums and bigfloats Fortran lacks never useful for scientific
computations?

Bruno Haible
hai...@ma2s2.mathematik.uni-karlsruhe.de

David F. Skoll

unread,
Jan 22, 1993, 9:45:57 PM1/22/93
to

>hmm... what makes a general purpose language? does providing lots of special
>functions have anything to with it?

Providing lots of special-purpose functions which cannot be removed at
run-time is bad news. I have no problems with lots of special-purpose
functions, but you shouldn't be forced to have them all, whether you
need them or not. The CL standard makes no provisions for excluding
some functions from a run-time environment. I'd bet that most
CL implementations can't be made much smaller than their full
(bloated) size.

>i think you can turn the argument around (classic usenet fashion) and say
>that functions that only print numbers in digits is pretty special purpose
>too. especially, functions that read and write floating point in base ten
>only (my personal beef - there's no reason it can't be done in other bases!).

There's a difference - how many programs have you written which
require numbers to be printed in base 10? In English? We're not
talking philosophical abstractions here - we're talking real-world
use.

>i think it's a nice little bonus feature. when do you ever use most of the
>functions in the UNIX C libraries? isn't it handy the one time in a hundred
>you need them - you can keep on truckin' instead of trying to figure out how
>to patch around the hole?

Absolutely. But if you don't want to use a certain C function, you don't
link it in. Your programs have no overhead for unused functionality.
If Common Lisp had some mechanism for this, then my criticism would not
be valid.

--
David F. Skoll

David F. Skoll

unread,
Jan 22, 1993, 9:50:43 PM1/22/93
to

>there are technical solutions to that problem, aren't there? i recall
>there being something called presto that would eliminate parts of lisp
>that weren't being used.

Two problems - it's a bit of a "kludge" - for best performance, you
have to "train" presto to recognize which parts should be loaded and
which shouldn't. That's a bit tedious and adds nothing to your
productivity. Secondly, it's not part of the CL standard, so if you
port your software to another implementation, there's no guarantee
that it will have presto.

--
David F. Skoll

Erann Gat

unread,
Jan 22, 1993, 11:09:48 PM1/22/93
to

There is an ongoing discussion on comp.lang.lisp.mcl which might be of
interest to followers of this thread. The discussion centers on the issue
of how to produce small applications using Lisp. The suggestion has been
made that Common Lisp should be considered an operating system and not
an application. In that case, having a zillion obscure functions is no
more unreasonable than having a large C library. (BTW - MCL (Macintosh
Common Lisp) implements all of CLTL2 and is 1.5 Megabytes, about a tenth
the size of Allegro.)

Erann Gat
g...@aig.jpl.nasa.gov

Randy Crawford

unread,
Jan 23, 1993, 2:30:29 AM1/23/93
to

Far be it for me to speak for Larry, but I've been reading this thread
long enough to see that the other side of the story isn't being told.
So here's my tuppence.

In article <1993012216...@SUMMER.SCRC.Symbolics.COM> S...@stony-brook.scrc.symbolics.com (Scott McKay) writes:
> Date: Thu, 21 Jan 1993 18:06 EST
> From: Larry Wall <lw...@netlabs.com>
>

> : In what way is Lisp "bland ... all the way through"?
>
> There's little visual distinctiveness to distinguish mentally
> distinctive constructs.
>
>This is simply not a valid criticism. There is little visual
>distinctiveness in English to distinguish mentally distinctive
>constructs, and yet you do not fault English. In fact, one could argue
>that "visual distinctiveness" is a principally a matter of typography.

Not a good analogy. Not only is english an unstructured language (as
compared with programming languages) but parsing english is legendary
for its difficulty. Without punctuation and semantic context, it's
trivial to write correct english which is effectively illegible; that's
illegible to man _or_ machine. The same is not true even of obfuscated
C; compilers handle it nicely. So legibility in english is _not_ a
simple matter of typography.

Likewise context free languages can be difficult to read for more reasons
than just syntactic sugar. There's little debate that unindented Lisp is
just as hard to read as unindented C, but few of us write unindented C,
and ALL Lisp is partly unindented any time two parens are adjacent.

However I think the real case to be made for Lisp's relative illegibility
is one of procedural languages vs. functional languages. When a process is
decomposed into separate tasks which are presented sequentially, the reader
has the least work to do in understanding the intent of the programmer.
Whenever processes are nested and one process generates temporary values
which are then fed directly into other processes, as in Lisp, the delineation
between tasks (prior vs. successor) is less clear. Certainly we don't write
english sentences from the inside out, why should we expect programmers to
read source code which is written that way?

>
> : Are you saying that you think that the true challenge in programming
> : is the actual struggling with the language, rather than the addressing
> : the deeper issues (such as, what it is you are trying to do)?
>
> I haven't noticed people struggling that much less with Lisp than with
> most other languages. Admittedly, nroff is a bit tougher, unless
> you're just trying to do text processing... :-)
>
>Perhaps it is the sort of software I do, but I emphatically do notice
>people struggling more with most other languages than with Lisp. Let's
>look at memory management, for instance. In most other languages, such
>as C, programmers must confront the issue of memory management head on,

>[...] The point is that, in most other


>languages, programmers must immediately tackle programming tasks that
>are only incidentally related to the problem at hand.

I see two ways to interpret what Larry said. One is to state that Lisp's
bag of tricks is no bigger than that of other languages. How readily does
a language protect the programmer from having to consider implementation
details like precision loss or the free use of memory? Does it provide
sufficient resources to off-load the myriad system support details which
are tangential to implementing an algorithm? I'd say that any language
as large as CL probably _is_ going to serve a programmer's every need,
albeit one-size-fits-all. But I don't think that's the better case that
can be made against Lisp, although that seems like what you defended.

The other perspective is one of general expressibility: does Lisp succeed
where other languages fail in producing readable source code and efficient
executables, leading to maintainability, modularity, and extensibility?
To answer this, Lisp must be compared on its own merits, without CLOS or
Genera. When stripped of its extensions and superb development environment,
Lisp doesn't appear to me to have a clear upper hand over a language like
Modula 2 or even Ada, not in any general sense. It's not more legible,
more intuitive, more efficient in execution. Lisp fares most poorly (IMHO)
when compared like this with newer languages like Modula 3, which were
designed largely for their legibility and modularity.

It's from this point of view that I too would say that I've seen few people
struggling more with Ada or Modula 3 than with Lisp. Compare the mysteries
of writing in Motif or Wcl with writing in CLIM or Clu. Not so different.



>
> : In what way does Lisp "push down so hard" on morphology?
>

> Essentially, Lisp assumes that humans like to write programs the same
> way the machines like to execute them, and so conflates the human
> representation with the machine representation. True, there are Lisp
> compilers, but the "ideal" is still that the machine and the programmer
> are interpreting the exact, same, one-size-fits-all data structure.
>
>I fail to see that Lisp makes any such assumption. What machines
>directly execute mapping operators? Reduction operators? What machines
>directly execute generic arithmetic, including integers, large integers,
>floating point, and ratios? Hash tables? Sequences and collections?
>This claim just cannot be made to stick.

Prefix notation and functional expressions are two `gotos considered good'
in Lisp. Violating either of these will either shut down your equations
or excommunicate yourself from the Brotherhood. They're both proscriptive.

>
>I also think you have confused what you call "machine representation"
>with "parsed representation". The fact that the human-readable
>representation is the same as the basic parsed representation is one of
>the great sources of Lisp's power -- it allows Lisp programs to
>effortlessly talk about Lisp programs.

Sort of the effortless way that Forth programs read?

>
> That said, I should back off a little and admit that there are a few
> things that are easier in Lisp than in other languages. But your
> assumption seems to be that it's better to use an all-around mediocre
> language for most everything than to use each language for what it does

> best. [...]


>
>I don't claim that Lisp is an all-around mediocre language. It's an
>all-around excellent language. Sure, there are some languages that have
>a few features that are better than what I can find in Lisp, but so what?

> [...]
>For general programming, I'll take Lisp nearly every time. Moral: use the


>right tool for the job.

Perhaps by choosing an all-around excellent language? :-)

Lisp isn't the most legible language, nor the fastest in execution, nor the
smallest in executables, nor the most portable among OSes, nor the easiest
to integrate with 3rd party applications. These are all excellent reasons
to prefer other languages when these considerations outweigh Lisp's
comparative strengths in rapid prototyping, implementation sbstraction,
flexible data structures, and run-time flexibility. In the PC applications
arena or systems or networking or communications or accounting or number-
crunching or distributed software, Lisp isn't even in the running.

THAT'S why Lisp isn't a mainstream language.
--

| Randy Crawford craw...@mitre.org The MITRE Corporation
| 7525 Colshire Dr., MS Z421
| N=1 -> P=NP 703 883-7940 McLean, VA 22102

ROBERTO AVANZI

unread,
Jan 23, 1993, 3:19:00 AM1/23/93
to
In article <dfs.727729181@crusher> d...@doe.carleton.ca (David F. Skoll) writes:
>In <1jpe0q...@tamsun.tamu.edu> hmue...@orca.tamu.edu (Hal Mueller)
>writes:
>
[things omitted]

>
>I like Lisp. I've worked on a large CAD program, and for that, Lisp
>was great. But for small-to-medium programs, I find the overhead of
>Common Lisp way too high.
>
>--
>David F. Skoll
I like Lisp too, while sometimes i HAVE to resort to C or 68020 asm
for my daily programming. but time passes and i use C less and Lisp
more. I am writing "LIsp" and not "Common Lisp" here because i prefer Scheme.
It is not a mere matter of taste. Scheme is more powerful for building
constructs, due to more powerful continuations, while CL has a much larger
library and a standard Object system. anyway, a lisp language can be used
also for very small projects... MacGambit runs on 2 meg macintoshes, as
well on powerful Quadras, while PC Scheme manages to fit in the ridiculous
less-than-640-k-or-change-os amount of memory of MesSy DOS.
If you need more powerful libraries, just look around . MIT CScheme for
example already has them built-in, with good systems such as Elk or
Gambit having no trouble in growing and growing with the user.

My 2 cents about "Why is not lisp a mainstream language" are as follow.
i) people think lisp <=> AI . it's false we know, but most people think so.
a friend of mine (and and intelligent person) asked me: why do you
use Lisp, AI has failed in its objectives...
ii) people hate parentheses. But still I do not understand why do they not
use forth instead then ...
iii) Lisp has been since recent times a resource hog. now its a false
statement, we have light lisps. but when allegro on a sparc gives you
a 11meg image, well, I believe something is wrong with allegro...
iv) a lack to a good interface to C routines. NOT OS interface, but generic
C code. I mean a STANDARD way. CMUCL, Lucid, Allegro all offer such
facilities but they are incompatible. That's bad.

Cheers
Roberto

Jim Carden

unread,
Jan 23, 1993, 10:26:01 AM1/23/93
to
[[** Posted for pa...@goldfish.mitron.tek.com **]]

In article <1993Jan23.0...@linus.mitre.org> craw...@boole.mitre.org (Randy Crawford) writes:
>However I think the real case to be made for Lisp's relative illegibility
>is one of procedural languages vs. functional languages. When a process is
>decomposed into separate tasks which are presented sequentially, the reader
>has the least work to do in understanding the intent of the programmer.
>Whenever processes are nested and one process generates temporary values
>which are then fed directly into other processes, as in Lisp, the delineation
>between tasks (prior vs. successor) is less clear. Certainly we don't write
>english sentences from the inside out, why should we expect programmers to
>read source code which is written that way?

There's an interesting point. What other notations are there to improve on this?
The most common is naming intermediate values. For this I prefer CL and Scheme's
LET or Dylan's BIND to C's (and Pascal, Ada, Modula, etc.) assignment semantics.

I use LET throughout my code and rarely have deeply nested functional expressions.

>When stripped of its extensions and superb development environment,
>Lisp doesn't appear to me to have a clear upper hand over a language like
>Modula 2 or even Ada, not in any general sense. It's not more legible,
>more intuitive, more efficient in execution. Lisp fares most poorly (IMHO)
>when compared like this with newer languages like Modula 3, which were
>designed largely for their legibility and modularity.

These are mostly subjective values, so to each his own. Modern LISPs' lexical
scopes, closures, and macros allow me to be significantly more expressive
than with any of the other languages you mentioned. (I have programmed extensively
in CL, Scheme, C, and C++. I have used the others enough to know what they're
like.)

>Prefix notation and functional expressions are two `gotos considered good'
>in Lisp. Violating either of these will either shut down your equations
>or excommunicate yourself from the Brotherhood. They're both proscriptive.

I could build a calendar based on threads like this one just as accurate
as the Mayan's. This is a recurring, subjective topic. Your mileage will
certainly vary.
--
Patrick Logan, pa...@goldfish.mitron.tek.com, (503) 690-8350

Pete Grant

unread,
Jan 23, 1993, 10:26:56 PM1/23/93
to
In article <C1773...@dei.unipd.it> gan...@sabrina.dei.unipd.it (ROBERTO AVANZI) writes:
>In article <1993Jan20....@netlabs.com> lw...@netlabs.com (Larry Wall) writes:
>>
>>Please reply in Lisp, not English. It's so much more expressive...
>>
>>Larry Wall
>>lw...@netlabs.com
>
>: (GETPROP 'LISP 'BEAUTY)
>"MARVELOUS"
>
>: (GETPROP 'PERL 'USEFULNESS)
>"GREAT"
>
>Cheers
>Roberto Avanzi

Cute, but what dialect? I assume GETPROP <=> GET??

Pete.

Barry Margolin

unread,
Jan 23, 1993, 2:28:39 PM1/23/93
to
In article <1993012216...@SUMMER.SCRC.Symbolics.COM> S...@stony-brook.scrc.symbolics.com (Scott McKay) writes:
>I personally think CAR and CDR could have been flushed from the
>language, since FIRST and REST do the exact same thing.

FIRST and REST only make sense when a cons is being used as a chain in a
list. CAR and CDR make much more sense for conses being used as pairs.
Their lack of preexisting semantics fits in with the abstract nature of
conses: calling them CONS-PART1 and CONS-PART2, for instance, would imply
an ordering to the components that doesn't necessarily exist. Flushing CAR
and CDR would make almost as little sense as flushing NOT because it's
equivalent to NULL.

Perhaps conses as fundamental data types should have been removed when
DEFSTRUCT was included in the standard. CONS could be defined as:

(defstruct (cons (:conc-name ""))
car cdr)

> What machines
>directly execute mapping operators? Reduction operators?

Connection Machines!

> What machines
>directly execute generic arithmetic, including integers, large integers,
>floating point, and ratios?

Lisp Machines?
--
Barry Margolin
System Manager, Thinking Machines Corp.

bar...@think.com {uunet,harvard}!think!barmar

Christopher Ian Connolly

unread,
Jan 24, 1993, 3:10:50 PM1/24/93
to
In article <1993Jan21.2...@netlabs.com> lw...@netlabs.com (Larry Wall) writes:
>In article <1993012019...@SUMMER.SCRC.Symbolics.COM> S...@stony-brook.scrc.symbolics.com (Scott McKay) writes:
>: In what way is Lisp "bland ... all the way through"?
>
>There's little visual distinctiveness to distinguish mentally
>distinctive constructs.

Uh, so English is just as bland? Or should we be using curly braces
instead of parentheses? Syntactic Sugar...help!...I'm going
hyperglycemic!! Somebody change my readtable...quick!!
Christopher Ian Connolly conn...@cs.umass.edu
Laboratory for Perceptual Robotics wa2ifi
University of Massachusetts at Amherst Amherst, MA 01003

Chris Cannam

unread,
Jan 25, 1993, 9:15:29 AM1/25/93
to

All right. Not a subject I know all that much about, but it's quite
interesting.

In article <EMCOOP.93J...@bcars148.bnr.ca> emc...@bnr.ca (hume
smith) writes:

- the draft is silent about what to do with nonpositives, especially
for roman numerals.

Should it do anything useful for nonpositive Roman numerals? After
all, the Romans didn't even use nonpositive numerals, so why should
you? There's surely no reasonably Roman representation of zero.

should the english cardinal of -1 be "minus one" or
"negative one"? (i prefer the latter - minus, to me, is the operator
not the additive inverse.)

I usually prefer the former, because presumably the intention is to
produce text that is smoothly readable to people without scientific
backgrounds. `Negative one' reads like a scientific term; `minus one'
reads like English. Yes, of course, you can then run into problems
with mixing `minus' as unary and binary operators, but if you want
clarity and consistency above everything, you shouldn't be trying to
write in English.

- which english style should BIG numbers (such as Mr. Skoll provided)
be written into? i assume, since it's the AMERICAN national standards
institute, they mean the american way - million, billion, trillion,
etc. not the english million, milliard, billion, billiard (?), etc.

I think most British are probably just as familiar these days with the
American numbering as with the British, but I don't think it's safe to
use either with British English speakers unless you're quite clear
about which you're using.

or will the standard permit/expect adaption to locale, using milliard
in York and billion in New York?

Things could get a bit confusing this way, but of course if it's
cuteness value you're after, well, why not?

does the usual system locale setup stuff
even handle this kind of information?

I very much doubt it.

(and to Mr. Mueller: i've written such an expander in Basic; it really
isn't so bad. the three-digit cycle helps a lot.)

Anyone remember `Lords of Midnight' (and its sequel), the computer
games that formatted numbers in a sort of antique style: Two hundred,
four score and ten brave warriors have boldly snuffed it, etc.?

Chris

--
on sighting mathematicians it should unhook the algebra from their
minds and replace it with poetry; on sighting poets it should
unhook poetry from their minds and replace it with algebra

Bruce Krulwich

unread,
Jan 25, 1993, 11:22:51 AM1/25/93
to

> You are right. I wrote my article hastily. But the "format" function is
> representative of one aspect of Common Lisp which I believe prevents it from
> becoming a "mainstream" language - Common Lisp attempts to do almost
> everything, with the result that 90% of the Lisp image is devoted to
> functions a small-to-medium program will never use.

It seems to me that if you mentally think of the language spec as what in
other languages would be "language + standard libraries," things make much
more sense. The fact that LISP systems are based on run-time environments and
REPL modes makes it hard to provide a good seperation between the two, and in
any case from a language definition point of view there's no diffference
(unless you want things to be optional, the way scheme does).

Bruce


David F. Skoll

unread,
Jan 25, 1993, 12:06:25 PM1/25/93
to
In <KRULWICH.93...@zowie.ils.nwu.edu>
krul...@zowie.ils.nwu.edu (Bruce Krulwich) writes:


>It seems to me that if you mentally think of the language spec as what
>in other languages would be "language + standard libraries," things
>make much more sense. The fact that LISP systems are based on
>run-time environments and REPL modes makes it hard to provide a good
>seperation between the two, and in any case from a language definition
>point of view there's no diffference (unless you want things to be
>optional, the way scheme does).

I think the paragraph above sums up nicely why Lisp is not a
mainstream language. Having to "think" of it as something else is not
something most programmers want to do. They want a language that's
portable, small, standard and cheap. Common Lisp programs are (in
theory) quite portable, but in practice are no more portable than C
programs. Common Lisp is not small, so it's not that good for small
applications. And Lisp is not cheap - if you want to distribute Lisp
applications, you usually have to pay $$$ to the Lisp vendor to
distribute Lisp run-time licenses. Also, the good Common Lisp
compilers are not free - are quite expensive, in fact. Compare this
to C, for example, which has no run-time royalties, and has a free
ANSI-standard compiler.

Another problem is that Lisp enthusiasts are not that good at
marketing Lisp. :-) When you tell people "well, think of this as..."
they switch off. :-)

--
David F. Skoll

Richard Lynch

unread,
Jan 25, 1993, 1:07:04 PM1/25/93
to
In article <dfs.727729181@crusher>, d...@doe.carleton.ca (David F. Skoll)
wrote:

> Actually, it wouldn't be too bad in C (if you can ignore the
> fixnum/bignum problems :-)) I agree that Lisp has many built-in
> conveniences. Maybe too many - we have Allegro Common Lisp on our Sun
> network, and the image is 11MB long. That's a huge overhead, and
^^^^

> anyone supporting the full Common Lisp spec probably couldn't do it in
> much less.

Ye Gods! And we're complaining about the 2.5MB size of MCL!!!
[Yes, it's full Common Lisp spec.]

Bill York

unread,
Jan 25, 1993, 2:36:47 PM1/25/93
to

There is an ongoing discussion on comp.lang.lisp.mcl which might be of
interest to followers of this thread. The discussion centers on the issue
of how to produce small applications using Lisp. The suggestion has been
made that Common Lisp should be considered an operating system and not
an application. In that case, having a zillion obscure functions is no
more unreasonable than having a large C library. (BTW - MCL (Macintosh
Common Lisp) implements all of CLTL2 and is 1.5 Megabytes, about a tenth
the size of Allegro.)

Actually, the true beauty of the suggestion was the part where you
take the entire Lisp application, call it an extension (apologies to
the non-Mac-fluent) and have people drop it in the System Folder.
After all, it isn't much bigger than Quicktime. Then you disguise the
fasl files as "applications" and sit back while everyone marvels at
the compact-but-powerful programs! And they can inter-operate, too!

Marty Hall

unread,
Jan 25, 1993, 2:54:01 PM1/25/93
to

No, no, all this misses the point. The *real* reason I like LISP is because
all of the following could be legal:

(rationalize My-Behavior)
(setf (car Marty)
'Lamborghini)
(make-instances-obsolete IBM-PCs)
(export 'Arms)
(dribble "Basketball")
(coerce My-Boss Raise)
(proclaim '(inline skates))

- Marty

Marty Hall

unread,
Jan 25, 1993, 3:05:23 PM1/25/93