Why Isn't Lisp a Mainstream Language?
M. Bersohn
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
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
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
>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
|> 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
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
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
>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
|> 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
Tom Pole
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
Yes, that last part was the commercial,
Thomas
--
Thomas Pole
k p c
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
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
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
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
: 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
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
>
> 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
;;;
;;; (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
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
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.
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.
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
>
>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
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
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
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
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
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
: 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
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
>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
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
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
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
>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
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
>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
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
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
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
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
there being something called presto that would eliminate parts of lisp
that weren't being used.
Carl L. Gay
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
> 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
>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
>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
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
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
>In <1jpe0q...@tamsun.tamu.edu> hmue...@orca.tamu.edu (Hal Mueller)
>writes:
>
>
>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
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
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
>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
>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
>: 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
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
> 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
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
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
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
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
(Pete Halverson) writes:
[...]
>Personally, when I'm comparing languages, syntax is way down on my list.
[...]
>Why, then, do others make such an issue of Lisp's syntax?
One reason, in my experience, is the context in which they were introduced
to LISP. I teach AI and AI Programming to MS students at Johns Hopkins.
Almost without exception, students who come into my classes with a smattering
of LISP background (eg in an undergrad course) are biased against the syntax
*from experience*. They were generally introduced by people who were not
serious LISP programmers and in a context (an AI course) where understanding
the language was not a priority. Few heard anything about LISP style or the
importance of indentation or the ideas of functional programming. Not
everyone who takes the AI Programming course here turns into a LISP zealot,
but I do think it is fair to say that few are still troubled by the syntax.
- Marty
(proclaim '(inline skates))
Marty Hall
S...@stony-brook.scrc.symbolics.com (Scott McKay) writes:
I have great respect for Scott's abilities, and agree with his major
points. On the following minor nit, however, I disagree:
>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.
I agree when one is working with lists. However, occassionally one uses
cons cells for other things (eg trees), and CAR/CDR (or even LEFT-POINTER and
RIGHT-POINTER) are preferable then, IMHO. I'd rather have a meaningless
name in such a case than one like FIRST where the current use contradicts the
meaning. But this is obviously a minor point.
On the real issue of why LISP is not mainstream, most of the comments I've
seen have focused on the user's perspective. However, I think there is also
a commercial reason having to do with the "bundledness" of Common LISP. I've
become convinced that since Common LISP is so big, only a few vendors had
(have?) the manpower to tackle it. There were good technical reasons against
going with a small core language with optional libraries for Common LISP,
but it did make it a lot harder for vendors to break in. If you could buy
CLOS from one person (and still have it optimized, which is hard, I realize),
FORMAT from another, LOOP from a third, CLIM from Scott, a development
environment from yet another, and so on, more small companies could have
entered the market. Right now it is hard for companies to carve out a
niche; they sort of have to go after the LISP market whole hog.
As a user, I'd rather be able to count on everything being there in any
implementation, and I realize it may be convenient to able to assume CLOS
is built in (when writing the condition system, for instance). But these
conveniences had negative implications in the commercial marketplace.
On an only slightly related note, I'm unaware of the licensing rules, but
perhaps the availability of CMUCL, WCL, and PCL will provide an avenue for
smaller vendors to get up and going more quickly. And perhaps CLIM will
provide a standard so that we can realistically buy (and sell) graphics
applications that lots of people could use...
Flemming Vestergaard
>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!
Well, it is fun. But from this corner of the world I suppose that it is
a more serious problem (if not a disaster) that Common Lisp provides
input and output functions that are suited only for English/American.
(format t "~R" 4) -> four really doesn't help very much in most of the world.
And yes-or-no-p cannot be used either.
I do think it is a mistake to include natural language specific functions
in a language standard.
Flemming
Wayne Throop
:: Message-ID: <1993012019...@SUMMER.SCRC.Symbolics.COM>
:: From: S...@stony-brook.scrc.symbolics.com (Scott McKay)
:: In what way does Lisp "push down so hard" on morphology?
: From: lw...@netlabs.com (Larry Wall)
: Message-ID: <1993Jan21.2...@netlabs.com>
: 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.
No. No, I'm sorry, but you've gotten it all wrong.
Lisp is one of the original three elven-rings, untainted by Sauron's
direct touch. It is the Ring of Symbols, most often called the Ring of
Lists. The others are the Ring of Numbers (called the Ring of
Formulas) and the Ring of Bureaucratic Records (called the Ring of
Business, or the Ring of Counting Beans).
But then Sauron tricked the Practical Smiths into forging the
nine-and-ninety Fortran and Regex Variant Rings, and gave them to
the mortal men doomed to die. Among them, C, C++, Awk, Perl, Bliss,
and so on.
And let us not forget the seven-and-seventy Algol Variant Rings, given
to the dwarf-lords in their halls of academia. Pascal, Modula-II,
Oberon, and so on. (I concentrate mainly here on the work Sauron
tricked the WirthSmith into forging.)
And then he attempted to make the One Ring, the Ring that would combine
and control the powers of all the Fortran and Algol Variant Rings,
corrupting and circumventing the Original Rings, and rendering all their
users his helpless wage-slaves.
Lucky for all of us, Sauron outsmarted himself. So many other Beings
were forging Rings of Power along many, many other dimensions during
these troubled times, that the cross-fertilization in the Ring-Forging
business made it nearly impossible to capture all their powers in the
One Ring. The Object Rings, the Functional Rings, the Rings of
Inference. Ada's attempt to be all rings to all peoples largely fell
apart, and so the Original Rings, the Practical Rings, and even the
Academic Rings can nowadays be used safely without fearing the
One Ring.
Which is as it should be, I suppose.
But notice that the Eldest Ring, Lisp, is still around after many
another has faded. It has adapted to the advent of the Object Rings,
the Inference Rings, and even to some extent the Functional Rings.
This is something that is largely missing in the Practical Rings. Once
a Practical Ring like Perl or TCL or C++, or even an Academic Ring like
Modula II, has been cast and decorated with their elaborate engravings
of lexical and syntactic charms (no doubt pleasing to the eye in some
ways), they seem to lose the ability to adapt and subsume
new models of programing.
Yes, C++ is an attempt to add the power of the Object Rings to an older
Practical Ring. And yes, TCL has had several attempts to incorporate
Object Ring powers. But nevertheless, the Eldest Ring, with its lack
of ornamentation, is better able to reflect the job at hand in its
smooth surface, instead of being permanently carved to do the job or
jobs that were at hand once upon a time.
- -
Wayne Throop ...!mcnc!dg-rtp!sheol!throopw
Michael Fleming
your name."); seems quite similar to (print "type your name"). Why
is one prefix and the other something else? Prefix notation is also
common in English. We say "Put the letter in the slot" not "letter
put slot." Or "the letter put in the slot". I am puzzled by the
complaint that a drawback of Lisp is its use of prefix notation.
I agree that a complex math expression can be difficult in prefix,
but the same expression is usually difficult in infix as well.
* Origin: The Interocitor*AI/Robotics*214-258-1832 (1:124/2206)
Fernando Mato Mira
>
> Well, it is fun. But from this corner of the world I suppose that it is
> a more serious problem (if not a disaster) that Common Lisp provides
> input and output functions that are suited only for English/American.
>
> (format t "~R" 4) -> four really doesn't help very much in most of the world.
> And yes-or-no-p cannot be used either.
>
> I do think it is a mistake to include natural language specific functions
> in a language standard.
Maybe some hooks should be provided to internationalize these functions. Then if
somebody needs to print checks in Spanish they can write their own routine to handle the ~R directive.
But even if the standard specifies the behaviour only for english, I think that thinking only "american" with respect to
the "billion thing" is quite irritating.
For yes-or-no-p it would be very easy (and extremely useful) to specify in the standard some system variables which you
could modify to hold the string appropriate for the local language.
And yes, I think CL is "a nice PL/1". And in the same way everybody around here seems to want everybody else to program in
LISP, I will be happy only when most LISPers program in SCHEME (with a good MOP, of course). Then I could get a lot of
public domain tools for it and abandon CL. If C++ is the black hole of OO programming, I must say that CL is the neutron star of list
processing.
--
Fernando D. Mato Mira
Computer Graphics Lab "Only CLOS is good enough"
Swiss Federal Institute of Technology ^^^^^^
mato...@di.epfl.ch
NeXTMail : mato...@lignext.epfl.ch
FAX : +41 (21) 693 - 5328
Disclaimer:
disclaim([],[]).
disclaim([H|T],[DH,DT]) :- fixed-point-disclaimer(H,DH),
disclaim(T,DT).
fixed-point-disclaimer(Text,fixed-point-disclaimer(Text,_)).
Jeff Dalton
>The obvious answer is almost TOO obvious. People prefer "horrible" languages.
Some do; others don't. I think it's a mistake to think one side or
the other must be wrong. That is: there's more than one good way
to do programming 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.
One thing this leaves out is that many people find Lisp more readable
and easier to understand than other programming languages.
Jeff Dalton
>I wonder, if it is possible, to change the synatx of LISP without
>loosing it's advantages.
You mean it's other advantages? For many of us, Lisp's syntax is
an advantage, not a disadvantage.
-- jd
Jeff Dalton
>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...
I can understand this reason, but I'm not sure what it's really
about. In what way has AI failed, in this view? What did these
people think AI was trying to do? Over-hyped, sure, but what was
the _failure_?
>ii) people hate parentheses. But still I do not understand why do they not
> use forth instead then ...
It's true that many people dislike Lisp syntax. But some people who
dislike it can grow to like it once they see how it "works". It isn't
necessary to pay attention to individual parens when reading
well-indented code, and the editor should take care of the problem
when writing. People who aren't used to well-indented Lisp don't
know the conventions and so can't see what's going on w/o being
distracted by the parens.
>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...
Something is wrong with a lot of Lisps. I know people who like Lisp
but who don't want to use it because their programs are so much bigger
and slower than if they use C. This is for windows-and-graphics sorts
of things. Lisp started with a huge lead in this area and threw it
away.
>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.
I agree.
-- jeff
Ms. Priscilla Walther
> - Marty
As a newcomer to the language, and a relative newcomer (undergrad) to
programming in general, from experience I can confirm, from a different
perspective, much of what you've said.
Since LISP _does_ have a repuatation for being hard to learn I did have
some concerns about the language. On the other hand, during my
third semester programming course, I had a professor who, while teaching
our class (using Pascal), spoke so highly of Lisp, so often, that many of the
students were intrigued by his praise for the language. This has resulted in
a couple of us taking a winter-session course to see what the language
has to offer, and I must say that I enjoy the language very much. It's
so flexible and free from what I would call 'constraints', that I feel
very comfortable with it. I have also found that, since the syntax is simple,
I am free to concentrate on the problem that I am trying to solve, rather
than syntax, type declarations, etc...
Concerning the matter of people feeling uncomfortable with the large
number of parens used, (referring to other posts -sorry for not including
them here), I didn't find that to be difficult since our version of EMACS
blinks the corresponding paren. And lest anyone think that my being
comfortable with 'thinking in parens' might be due to a strong Math
background, let me just say that Comp. Sci. is my second major,
my first major being Ancient Studies (Ancient History & Languages etc.)
and until 18 months ago, I hadn't taken any Math for over 15 years.
(No flames intended, just an observation.) What I _did_ find, is that
the parens required a precision of thought that was challenging, yet
gratifying.
As a final note, then, I would say, yes, in the beginning, my attitude
toward LISP was influenced by a professor whom I respected, and who spoke
positively regarding the language. I would also say that being
'positively oriented' probably facilitated my ability to pick up the
language. The question then, is, in comparison with C and Pascal
(remember, I'm giving you the newcomer's point of view, so I can't give
you a massive list :) of languages with which I have experience), which
language would I choose? Without a doubt, LISP. Too bad I have to
go back to writing in C and Pascal next week.
--
Priscilla Walther
hume smith
well it IS the AMERICAN standard. ISO may (should) make a different one.
i personally think there should be something way, from system locale
resources, to figure out local customs. it shouldn't be too hard to
have hooks of some sort for ~R, so local number-spelling functions
can be slipped in.
--
Hume Smith Honour sick and davey cris-cross
hume....@acadiau.ca McTruloff sentimie
emc...@bnr.ca A parsnip inner pair threes.
John D. Burger
Not only is english an unstructured language (as compared with programming
languages) ...
Well, any grammar for English would be far larger and more complex than for any
programming language (except maybe CommonLisp :), but I don't think I'd call
English unstructured.
... but parsing english is legendary for its difficulty.
Hmm, I have very little difficulty. :)
Without punctuation and semantic context, it's trivial to write correct english
which is effectively illegible; that's illegible to man _or_ machine.
You must make a distinction between syntactic correctness and understanding. I'm
not sure which you mean by "illegible", but if I can't parse your trivially
written sentence, and few other English speakers can either, then it ain't
English, by definition.
On the other hand, maybe you meant "understand-ability"; you're correct in that
it's easy to construct syntactically valid English sentences that I can't
understand, but that's true for programming languages as well. I submit that the
C code for the phone system is not understandable "to man _or_ machine". It's
EXECUTABLE, but so what? Very little code is understandable, as in "what does
this do, in all circumstances", to machine. Witness all the research on program
verification.
Of course, none of this distinguishes Lisp from any other programming language,
but I just wanted to suggest that as far as "legibility" (which I read as
"understand-ability") is concerned, natural and programming languages are perhaps
not that different.
John Burger jo...@mitre.org
Arun Welch
... but parsing english is legendary for its difficulty.
You must make a distinction between syntactic correctness and understanding. I'm
not sure which you mean by "illegible", but if I can't parse your trivially
written sentence, and few other English speakers can either, then it ain't
English, by definition.
Back in the mists of time when I took a course on natural language
programming we were asked to parse "I saw the man on the hill with the
telescope". I seem to remember 7 different ways to parse it. It's
perfectly good, trivial english, you just need a whole lot of context to know
what's the right one.
This has gotten pretty far afield from the original discussion, but
none of these "reasons why Lisp isn't a mainstream language" seem
reasonable.
We can't change the syntax, it'll confuse more people than it'll
convert. I remember trying to teach people about the alternate syntax
provided by Interlisp, which provides the usual syntax, apply-form,
and infix form. It's too damn confusing, and it's just easier if you
learn the regular syntax. I know a lot of people who find the Lisp
syntax a lot easier to deal with than C's, for example.
Lisp images are large because there's a fair amount of other support
(Yes, I realise that MCL is only 2.5 Mb. However, how does that
compare with other programs on Mac's?) in the image, and yes, the
language definition is huge. There have been recent developments on
this score, like tree shakers and shared libraries. Besides, if
smallness of the language was an indicator why isn't everyone
programming in Scheme? SIOD will fit in 64K, if memory serves.
I think there are other reasons for Lisps non-popularity, some of them
historical. Lisp got tied in to the AI binge, and when AI busted it
took Lisp with it. There've been a lot of other myths about Lisp
raised through time too, most of which have stuck (Lisp isn't good for
number-crunching, Lisp is slow, etc.) no matter how untrue they were.
Some blame can also be put on the Lisp programmer community itself,
through pricing itself out of the market during the AI heyday. One of
Lisp's greatest features is it's extensibility, but this has also
resulted in the mudball theory of programming language design :-).
I think an associated question we should be asking is "How can we
increase Lisp's popularity"? Knowing why it isn't popular is a good
thing to discuss, but it would also be good to know where to go from
here. Another question is "Should Lisp be a mainstream language?" I'm
not sure the answer to that is yes. A lot of neat ideas have risen out
of Lisp not having been standardised to death early on. CLOS is a case
in point. If we'd standardised on Interlisp and LOOPS or Zetalisp and
Flavors I think we'd be a lot poorer today.
I'll stop now, I think this is certainly turning out to be an
interesting discussion.
...arun
----------------------------------------------------------------------------
Arun Welch
Lisp Systems Programmer, Lab for AI Research, Ohio State University
we...@cis.ohio-state.edu
Randy Crawford
>
> Not only is english an unstructured language (as compared with programming
> languages) ...
>
>Well, any grammar for English would be far larger and more complex than for any
>programming language (except maybe CommonLisp :), but I don't think I'd call
>English unstructured.
`The horse ran through the barn, fell.' No, English isn't entirely unstruct-
ured or else it'd be unintelligible. But the number of irregularities and
contextual dependencies makes it at least context sensitive, and fully
unrestricted as far as I'm concerned. That's pretty unstructured when
compared to CFG programming languages. (I refuse to consider English as
structured but complex. It's too much a product of messy evolution to claim
that.)
If it isn't relatively unstructured then it's relatively structured. There-
fore it ought to be relatively easy to specify rules for parsing it. Yet
that's shown itself to be *highly intractable*. So I consider English to be
comparatively unstructured.
So there. I've run rings around you logically.
>
> Without punctuation and semantic context, it's trivial to write correct english
> which is effectively illegible; that's illegible to man _or_ machine.
>
>You must make a distinction between syntactic correctness and understanding. I'm
>not sure which you mean by "illegible", but if I can't parse your trivially
>written sentence, and few other English speakers can either, then it ain't
>English, by definition.
So that's the definition of English. I always wondered. :-]
`The girl saw the boy on the hill with a telescope.' Legal English. Trivial.
I can think of at least four ways to parse this. By your definition, I'm
illiterate because I can't parse this.
I prefer to think that your definition of English is flawed.
>
>On the other hand, maybe you meant "understand-ability"; you're correct in that
>it's easy to construct syntactically valid English sentences that I can't
>understand, but that's true for programming languages as well. I submit that the
>C code for the phone system is not understandable "to man _or_ machine". It's
>EXECUTABLE, but so what? Very little code is understandable, as in "what does
>this do, in all circumstances", to machine. Witness all the research on program
>verification.
This is getting more philosophical than I intended.
The only compiler for English is a human. If the person can't figure out the
sentence, then it's useless. Programming languages are equally useless if
_their_ compilers can't make sense of them. If the programming language
source is unreadable to humans, then the programmer has written machine code.
Since nobody is lining up to program in hexadecimal these days, I have to
conclude that source readability is the reason. Ergo source code legibility
is important, whether it completely and correctly describes its intentions or
not.
If in fact Lisp is less legible than other programming languages, then that's
a justifiable black mark against Lisp.
>
>Of course, none of this distinguishes Lisp from any other programming language,
>but I just wanted to suggest that as far as "legibility" (which I read as
>"understand-ability") is concerned, natural and programming languages are perhaps
>not that different.
But they're not exactly equivalent either since no machine in the world is
capable of making sense of varied natural language. I hope the same isn't
true of your favorite programming language or you're going to need an
excellent memory to recall what all your code was originally meant to do.
Varol Akman
> [parts omitted]
>Take a look at all the baroque format directives in Common Lisp. I mean,
>who really needs the number 394829348234982435 formatted in English words??
>
I think I do! (But for Turkish words, and I think that would be easy to
do since there is a rather trivial 1-1 mapping.)
Here we fill a ridiculous government form every month (just to claim
some money back in return for receipts for goods with a value-added tax)
and the form won't be accepted unless you you write the sum total
in Turkish. Unfortunately my totals hardly approach the neighborhood of the
number you've cited :-) :-)
Varol Akman
Department of Computer Engineering and Information Science
Bilkent University, Bilkent, Ankara 06533, Turkey
E-mail: ak...@trbilun.bitnet
Bill Vrotney
In article <WELCH.93J...@sacral.cis.ohio-state.edu>
we...@sacral.cis.ohio-state.edu (Arun Welch) writes:
> I think an associated question we should be asking is "How can we
> increase Lisp's popularity"? Knowing why it isn't popular is a good
> thing to discuss, but it would also be good to know where to go from
> here. Another question is "Should Lisp be a mainstream language?" I'm
> not sure the answer to that is yes. A lot of neat ideas have risen out
> of Lisp not having been standardised to death early on. CLOS is a case
> in point. If we'd standardised on Interlisp and LOOPS or Zetalisp and
> Flavors I think we'd be a lot poorer today.
Yes "Where to go from here?" I am disappointed that the Lisp leadership is
not addressing this question. This begs for something like the Common Lisp
project but aimed at making Lisp smaller and faster in an organized way. I
was reading about a KERNEL lisp specification in Lisp and Symbolic
Computation. Perhaps something along these lines should be hit with force.
Lisp leadership where are you? Give us something to be hopeful for.
As far as Lisp's popularity. When Arabic numerals were first introduced to
people using Roman numerals it took them 400 years to convert to Arabic.
What's new? Forget the Lisp haters. Dwelling on why Lisp is not popular can
lead to no useful activity. If Lisp is a good idea it will still be here
after C++ is gone. Even if Lisp was "perfect" the Lisp haters would not want
to use it, so why try to make them happy. Let's make the people who like
Lisp happy for now, the rest will take its course.
If this thread is going to lead to anything useful I would hope it be to
expose Lisp's weak points and instigate a new Lisp direction to fix them.
For sure, most of those that worked on the Common Lisp project would delight
in an opportunity for another major refinement. Perhaps Clinton's new
technology direction will provide the money to do it.
--
Bill Vrotney
BAH/Advanced Decision Systems
Chris Dollin
(a) Imperatives in English are prefix, but declarative sentences are
infix (degnerating to postfix when there's no second argument); ``I
drink tea'', ``She abhores jazz'', ``This is an aardvark'', ``I swim''.
(b) In any case, ``infix'' is rather a weak term, sicne many
(programming) language structures ae mixfix; if-then-else-(endif),
while-do-(endwhile), etc, as well as providing infix operators.
(c) Infix operators are not confined to the usual mathematical ones;
consulting a piece of code I've just de-iconised, I see the following
infixes:
. x.f, evaluate x and apply f to it
->> val ->> var, assign and preserve value
-> val -> var, assign, don't preserve value
== x == y, x is-identical-to y (test)
/== x /== y, x isn't the same thing as y
:: x :: y, list with head x and tail y
> x > y, numeric greater-than
- x - y, numeric subtraction
+ x + y, numeric addition
>< x >< y, turn into strings and concatenate
*I* find ``x == y'' easier to read than ``(== x y)'' or ``(eq x y)'',
and at this point Your Kilometerage May Vary.
--
Regards | "Always code as if the guy who ends up maintaining your code will be
Kers. | a violent psychopath who knows where you live." - John F. Woods
Jim Mayer
(1) The major Common Lisp implementations that run under Unix are all
monolithic systems. They are also HUGE. This means that, as a
practical issue, it is very difficult to write SMALL programs in
common lisp. Shared libraries, eval servers, and (perhaps) various
extensions to the ANSI block compilation stuff could help but are
either unavailable or surprise prone.
(2) My experience with both Lucid and Franz implementations suggests
that using libraries implemented in other languages (typically "C")
doesn't work very well. There are several problems:
(A) The "foreign function" interface needs to be kept up to date.
Without automatic support this is tedious and error prone.
(B) There is no way to debug problems in foreign code.
(C) Wild pointers and array overflows in foreign code break the
entire system so that NOTHING can be debugged.
(D) Direct mappings of "C" library calls into foreign calls
usually yields an interface that is inferior to the native
interface and "weird" from a Lisp perspective.
(E) At least until multi-threaded "C" libraries are the norm,
using non-reentrant libraries from a multi-threaded
environment is trouble prone.
(F) Even without threads, a GC that moves objects can cause a lot
of trouble.
(3) "C++" programming environments are getting a lot of attention, and
are getting pretty good.
(4) Common Lisp I/O is poorly designed for systems tasks and is
typically very slow. Common Lisp streams suffer from the PASCAL
design flaw that supposes that files can be productively modeled as
big arrays. Standard Common Lisp streams are not extensible and the
usual CLOSish fix requires a generic dispatch per character or byte.
For fun, compare the overhead of "getc" in "C" with the overhead of a
generic function dispatch and a couple of slot fetches.
(5) There are a lot of libraries and support tools available for "C"
and "C++" programmers. These include window system support, database
interfaces, numerical computation libraries, parser generators,
lexical analyzers, etc. If they cannot be used easily and naturally
from Lisp, then any technical advantages that Lisp has will be swamped
by the practical advantages having those libraries available.
(6) I need to be able to share my results with my colleagues.
Given the current lisp implementations, a "C" programmer needs to
switch to a lisp environment in order to use any code that I might
write. He or she then needs to:
(A) Buy a lot more memory ($1,000) and some more disk ($1,000).
(B) Shell out $6,000 to $8,000 dollars for a Lisp development
environment.
So, having spent $10,000, my collegue gets to:
(A) Run my code.
(B) Work in a very, very, inverior "C" development environment.
This puts a real burden on me to write extraordinarily brilliant code.
So.... what (IMHOP) has to be done?
(1) Lisp implementors need to provide compilers that produce standard
object files that can be placed in libraries (both shared and static)
and that can be manipulated by the standard system tools.
(2) The lisp "core" needs to be provided as a shared library so that
"C" programmars can use routines written in lisp by adding no more
than "-llisp" to their "cc" command lines. The lisp core also needs
to be a lot smaller than it currently is on most unix boxes.
(3) Tools need to be provided to at least partially automate the task
of generating "C" interfaces to lisp code, and lisp interfaces to "C"
code.
(4) A natural mechanism for working with typed "C" pointers in lisp and
lisp pointers in "C" needs to be developed.
*** Flame retardant ****
Please note that I am quite aware that some of the above issues are
technically difficult, especially given the semantics of Common Lisp.
I am explicitly not talking about hows, just about whats. Furthmore,
my dealings over the years with people at both Franz and Lucid have
been very pleasant and productive.
--
-- Jim Mayer
Phone: (716) 422-9407
Webster Research Center Intelnet phone: 8*222-9407
Xerox Corporation Internet Email: ma...@wrc.xerox.com
800 Phillips Road, 0128-29E XNS Email: James L Mayer:Wbst128:xerox
Webster, New York 14580 Facsimile: (716) 265-7133
Greg Parkinson
In article <dfs.727981585@kehleyr>, d...@doe.carleton.ca (David F. Skoll) writes:
|> 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.
It depends on what you think is "quite expensive".
I wouldn't call $7500 outrageously expensive,
considering what you get. Compared to payroll
and hardware costs, it's negligible.
|> Compare this
|> to C, for example, which has no run-time royalties, and has a free
|> ANSI-standard compiler.
The run-time is a difference, but Franz will charge
you a one-time fee of $2500 for all the run-times
you want ($5000 if you're going to sell them.)
Again, not a whole lot of money.
Of course, it depends on your environment. I can
pay back the cost of a two-person-year project
including hardware and software by preventing
*one* mistake.
And fine, you can get a free C compiler. How much are
you going to pay for a development environment to match
what your $7500 for Lisp includes?
--
Greg Parkinson Phone: 212-657-7814 Fax: 212-825-8607
Citibank,111 Wall Street E-Mail: g...@fig.citib.com
New York, New York 10043
The opinions expressed are my own and not those of the big 'ol bank.
ro...@ute.columbia.ncr.com
jaf...@zurich.ai.mit.edu (Aubrey Jaffer) writes:
>Some things which could be added to SCM are:
> Profiling (how much time spent in each routine)
> Dynamic Linking (There is a GNU package which does this on Unix
> systems and Carrette has also suggested a fairly portable method)
> Editor (buffers + GNU search + curses)
> String Ports (someone has sent me code for this but I haven't had
> time to integrate it)
I vote for weak-cons so that Thomas (DEC's almost-Dylan) can be ported to it.
(BTW, SCM is very nice. Thanks Aubrey!)
Barry Shelton
ba...@ute.columbiasc.ncr.com
Jeff Dalton
>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.
But why does the _standard_ (or other language definition) have to
do this?
>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.
The C language has no mechanism for this. It's the linkers that do
it.
So, the right question is: is there something about the language
that rules out implementation strategies that omit unneeded code?
And the answer is "yes". Almost anything could be called, eg by
(apply (read) (read))
So implementation either have to provide a way for the user to
say that only the functions that are directly called will be
called or else provide a way to load in functions when needed.
The latter approach has been around for a long time in the
form of "autoloading".
However, such tricks won't work very well if programs tend to
require most of CL, perhaps because CL is so intertwined. This
is a standard criticism of CL. ERROR requires FORMAT, etc.
But how true is it? Well, I think there's evidence that it's
sufficiently true to be a problem. On the other hand, why
should it be fatal. What if, for instance, CL is packaged as
a shared library (as in WCL)? It's a fairly big shared library,
but then so is X.
-- jd
Donald H. Mitchell
>
> As a final note, then, I would say, yes, in the beginning, my attitude
> toward LISP was influenced by a professor whom I respected, and who spoke
> positively regarding the language.
>
IMHO, Priscilla's hit the nail on the head. Most purchasing decisions
or choices of how to go about doing something are based first on
personal experience and second on recommendations from friends and
colleagues. You may violate this characterization by going out and
researching every purchase that you do; however, I doubt it. Your
choice of store to shop in, refrigerator model, *restaurant*, church,
etc starts with personal recommendations (or sometimes
advertisements). We've got to evangelize and perhaps stoop to
teaching introductory programming courses :-)
Note, IBM and MicroSoft don't corner their markets by quality,
price, or features but by familiarity, trustworthiness, and
marketing agressiveness. They've defined the battle: we must
fight it on their grounds. The same goes for languages.
>
> --
> Priscilla Walther
Don Mitchell dmit...@trc.amoco.com
Amoco Production Company (918) 660-4270
Tulsa Research Center
P.O. Box 3385, Tulsa, OK 74102
--
Don Mitchell dmit...@trc.amoco.com
Amoco Production Company (918) 660-4270
Tulsa Research Center
P.O. Box 3385, Tulsa, OK 74102
Scott McKay
From: Chris Dollin <ke...@hplb.hpl.hp.com>
*I* find ``x == y'' easier to read than ``(== x y)'' or ``(eq x y)'',
and at this point Your Kilometerage May Vary.
You hit the nail on the head when you said "*I* find". The only
reasonable conclusion one can draw about this bickering over syntax is,
that it is pointless. What syntax people prefer is a matter of taste.
I believe that an important point that is being lost in the shuffle is
whether or not the language is malleable enough to provide "control
abstraction" (analogous to the way classes, structures, etc., provide
data abstraction). If the language cannot provide good control
abstraction, then *it's not good enough*. (Of course, the lack of
control abstraction does not render a language useless any more than the
lack of data abstraction does -- it just makes life much more difficult
than it needs to be, and really, isn't programming is hard enough
already?)
In my opinion, almost every modern programming language fails to provide
control abstraction. One reason Lisp manages to provide it is that the
syntax of the language makes it easy to use Lisp as its own meta-
language. There are other ways to do this (e.g., add features to the
language that allow the language to talk about its own parsed
representation), but to the best of my knowledge, there aren't any
languages that do this in any serious way.
Gregory Vance Wilson
> Some things which could be added to SCM are:
Some other things that might speed its adoption by the rest of us:
* a textbook on software engineering which uses Scheme as a language for its examples
* " " " how to implement Scheme using C (good intro to systems programming)
* " " " operating systems
* " " " computer networks
* " " " graphics
* " " " databases
* " " " physical science
* " " " discrete event simulation
* " " " numerical methods
* " " " computational science (not the same as numerical methods)
My point is that most people who care a lot about language design don't care
(as much) about other aspects of computing. As a result, language designers
spend their time refining languages, instead of showing the rest of us how
useful they are. I don't want to be shown how to write a Scheme interpreter
in Scheme; I want to be shown how to implement Runge-Kutta, or an irregular
oct-tree for making my ray-tracing program go faster, or a traffic flow
simulator, or...
I think that C and Pascal (the only two new languages to have gained a
general following since the 1960s) have succeeded precisely because such
books have been, or become, available. "Give me the child to the age of
seven, and I will give you the man," and all that --- I believe that Scheme
(or ML, or any other language) will not be adopted outside a relatively
narrow segment of academia until (or unless) enough curricular material is
available for it to be the primary language of instruction throughout an
entire undergraduate degree.
Looking forward to the responses,
========================================================================
Gregory V. Wilson || Work as though you lived
Dept. of Computing and Information Science || in the early days
University of Oregon || of a better nation.
gwi...@cs.uoregon.edu || - Alasdair Gray
========================================================================
Aubrey Jaffer
In article <1993Jan27.0...@ads.com> bvro...@ADS.COM (Bill Vrotney) writes:
...
Every once in a while this thread pops up, with people lamenting over the
size of Common Lisp. Usually, someone (me, in this instance) will point out
that there is a small, standardized (IEEE) lisp around: Scheme.
I am crossposting this to comp.lang.scheme because I feel the point made above
applies to some extent to scheme as well.
Although the technical side of scheme has been very well handled, I find the
lack of scheme in the marketplace quite disturbing. According to the FAQ,
there is only _one_ commercial implementation of scheme running on UNIX
workstations (Chez Scheme).
I sell SCM, which runs on UNIX workstations, on MSDOS floppy disks.
This is as portable a medium as you are likely to find for UNIX
workstations. However, I am willing to put it on another format. The
FAQ probably does not mention me as a commercial vendor because SCM is
also availble via FTP.
There are several free implementations around, but all are either toy
implementations or are concerned with being an "extestion language" for
applications written in C.
SCM was written to be the base of a symbolic algebra program written
in R4RS Scheme.
As a result they have no compilers and no development environments.
If you are working on Unix workstations then there is no problem.
Emacs + psd1.0 provides source code single stepping and breakpointing,
code formatting and send-defun. SCM (through SLIB) provides trace and
untrace. I find this a potent combination.
The Hobbit Compiler (by Tanel Tammet) for SCM is in alpha test
and should be ready soon. However, as SCM runs only 15 times slower
than hand crafted C code (on most machines) and loads very quickly,
the lack of the compiler has not hampered my development efforts.
No foreign-function interface, for one.
There are directions for adding foreign-functions to SCM in code.doc
in the distribution. Many people have done so. So I think it is not
too difficult.
It can be argued that academia has done its job in presenting us with
extremely elegant standards (R4RS and IEEE), but the commercial sector has
dropped the ball.
Perhaps if I charged more, I would be taken more seriously. But
consider this: for the price of a "commercial" implementation
(n x $1000) you could hire me or someone else to add a substantial
amount of stuff to SCM.
Some things which could be added to SCM are:
s...@sef-pmax.slisp.cs.cmu.edu
From: bvro...@ADS.COM (Bill Vrotney)
Yes "Where to go from here?" I am disappointed that the Lisp leadership is
not addressing this question. This begs for something like the Common Lisp
project but aimed at making Lisp smaller and faster in an organized way. I
was reading about a KERNEL lisp specification in Lisp and Symbolic
Computation. Perhaps something along these lines should be hit with force.
Lisp leadership where are you? Give us something to be hopeful for.
-- Scott
===========================================================================
Scott E. Fahlman Internet: se...@cs.cmu.edu
Senior Research Scientist Phone: 412 268-2575
School of Computer Science Fax: 412 681-5739
Carnegie Mellon University Latitude: 40:26:33 N
5000 Forbes Avenue Longitude: 79:56:48 W
Pittsburgh, PA 15213
===========================================================================
John D. Burger
this post. I'm surprised there weren't more replies to my original post, it
was such a perfect flame magnet. :)
Randy Crawford (craw...@boole.mitre.org) writes:
The horse ran through the barn, fell.' No, English isn't entirely
unstructured or else it'd be unintelligible. But the number of
irregularities and contextual dependencies makes it at least context
sensitive, and fully unrestricted as far as I'm concerned. That's pretty
unstructured when compared to CFG programming languages
I'm not sure what your garden path sentence was an example of, but it's
certainly parseable, with or without the comma (which, by the way, I believe
would be considered ungrammatical by proscriptive grammarians). It even has
only one parse. As far as grammatical complexity is concerned, no one has
proven very convincingly that English, in particular, is syntactically
context-sensitive. Sorry. Even if English were trans-context-free, it
needn't be unstructured, by which you mean, I presume, something like
"having few formal requirements". And I don't know what "unrestricted"
means. "horse barn ran through the" isn't English, so English has some
restrictions, at least.
If it isn't relatively unstructured then it's relatively structured.
Therefore it ought to be relatively easy to specify rules for parsing it.
Yet that's shown itself to be *highly intractable*. So I consider English
to be comparatively unstructured.
Getting right all the nooks and crannies of a natural language grammar is
certainly hard. It hasn't yet been done. Nonetheless, systems exist that
correctly parse better than 99 percent of, say, the New York Times, or even
harder texts, correctly. Your may disagree, but I think that's possible
because there's lots of structure there. Of course, a C (or even Lisp)
compiler correctly parses much closer to 100 percent of its respective
language. It better.
If I can't parse your trivially written sentence, and few other English
speakers can either, then it ain't English, by definition
`The girl saw the boy on the hill with a telescope.' Legal English.
Trivial. I can think of at least four ways to parse this. By your
definition, I'm illiterate because I can't parse this.
I prefer to think that your definition of English is flawed.
I'm confused. You say "I can think of at least four ways to parse this",
then you say "I can't parse this". Is the problem that there is more than
one parse? That's certainly true. Nonetheless, the sentence can be parsed.
As far as my definition of English is concerned, I don't know what other one
there is. Maybe I missed the announcement of "ANSI English 93".
Rather arbitrarily, I'll stop now.
John Burger jo...@mitre.org
Kardan Kaveh
>we...@sacral.cis.ohio-state.edu (Arun Welch) writes:
>
>> I think an associated question we should be asking is "How can we
>> increase Lisp's popularity"? Knowing why it isn't popular is a good
>> thing to discuss, but it would also be good to know where to go from
>Yes "Where to go from here?" I am disappointed that the Lisp leadership is
>not addressing this question. This begs for something like the Common Lisp
>project but aimed at making Lisp smaller and faster in an organized way. I
Every once in a while this thread pops up, with people lamenting over the
size of Common Lisp. Usually, someone (me, in this instance) will point out
that there is a small, standardized (IEEE) lisp around: Scheme.
I am crossposting this to comp.lang.scheme because I feel the point made above
applies to some extent to scheme as well.
Although the technical side of scheme has been very well handled, I find the
lack of scheme in the marketplace quite disturbing. According to the FAQ,
there is only _one_ commercial implementation of scheme running on UNIX
workstations (Chez Scheme).
There are several free implementations around, but all are either toy
implementations or are concerned with being an "extestion language" for
applications written in C. As a result they have no compilers and no
development environments. Even MIT Scheme is not suited for serious,
production quality development (IMHO). No foreign-function interface, for
one.
It can be argued that academia has done its job in presenting us with
extremely elegant standards (R4RS and IEEE), but the commercial sector has
dropped the ball. Why, for example, do none of the CL vendors also have
scheme systems for sale?
Do we have to wait around for Dylan to appear? Scheme offers, to a large
extent, what Dylan promises at some uncertain time in the future.
Kaveh
--
------------
Kaveh Kardan ka...@taarna.UUCP
Systeme Taarna kar...@eole.umontreal.qc.ca
Montreal Quebec Canada (514)844-8448
Espen J. Vestre
>should it be fatal. What if, for instance, CL is packaged as
>a shared library (as in WCL)? It's a fairly big shared library,
>but then so is X.
...on Decstations X isn't even a shared library, which makes xclock half
a megabyte big :-)
(forgive me, decfriends, if things are better now than the last time I
used a Decstation!)
--------------------------------------------------------------
Espen J. Vestre, es...@coli.uni-sb.de
Universitaet des Saarlandes,
Computerlinguistik, Gebaeude 17.2
Im Stadtwald, tel. +49 (681) 302 4501
D-6600 SAARBRUECKEN, Germany fax. +49 (681) 302 4351
--------------------------------------------------------------
Jeff Dalton
>
>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.
Really? Perhaps this time, but the case against Lisp syntax is told
again and again, in my experience.
I'd like you to ask yourself something. How could _anyone_ (who wasn't
a complete idiot) possibly think Lisp was _easier_ to read than other
languages? Could it be that maybe, for them, it really is easier,
and that they aren't just confused or in the grip of "what they're
used to"?
Just what do you think the story is here? What's wrong with these
people, in your opinion?
>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.
As compared to ... what? For instance? Let's have some examples of
this visual distinctiveness. Let's have it compared to Lisp as
presented in Algol-ish style (ie, different fonts for different
things, as in some of the Scheme texts), or whatever.
> 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.
What? All languages are partly unindented every time two visible
characters appear on the same line, no? What exactly is the problem
in Lisp that you're referring to?
In properly indented Lisp, it isn't necessary to pay attention to
individual parens when reading the code. Even the general structure
of parens is largely redundant, serving chiefly to reinforce the
impression created by the indentation and our knowledge of the
operators involved. Programmers new to Lisp often try to make it
more readable by putting individual close-parens along on a line
(like they might with an "end" in Algol or a "}" in C). This
generally makes it _less_ readable.
>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.
Do you think functional languages such as ML or Haskell have this
problem?
Now, it's true that sequential is often easier to understand;
and that's one reason why Lisp programmers often write things
out sequentially. On the other hand, nested function calls
are used in almost every language. Lisp programmers are probably
used to a bit more complexity here than, say, C programmers;
but in well-written Lisp programs procedure definitions tend
to be fairly short, and the complexity of individual expressions
is kept under control.
Moreover, sequential isn't always easier to understand, which
is why we don't break every expression down into single steps
in (virtually) any language.
>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.
CLOS is part of Common Lisp. Let's deal with actual Lisps, please,
such as Common Lisp, Scheme, EuLisp, and Dylan, and not with an
abstract "Lisp". Common Lisp, EuLisp, and Dylan all have object
systems as part of the language. EuLisp and Dylan were designed
post-CLOS, and their object-oriented aspects are not extensions
even historically.
>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.
I might even agree with that as a general point, though I don't think
Modula 2 or Ada are very good examples. Indeed, I usually try to say
that some people (like me) find Lisp better (at least for a wide range
of tasks) and that there's more than one good kind of language. I
think Lisp is _a_ good language, but not the only one; and I don't
expect everyone to prefer the same kind of language.
Where I disagree is when people seem to be saying that Lisp is worse
than other languages. I don't think that is so, in general, though it
often is so for certain specific purposes.
>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.
To me, your entire argument more or less boils down to this: prefix
notation and functional expressions are bad. There's obviously
something to be said for this. However, for me and a number of other
people, it turns out that, all things considered, Lisp is more readable
than other languages. So either prefix notation and functional
expressions aren't as big a problem as some think, or else there
are compensating advantages. Because I just don't think we're that
different from everyone else.
This is not to say that everyone ought to see things our way. Nor am
I saying that it's entirely a matter of opinion or personal preference.
I think it's like this: when the alternatives in question are sufficiently
good, then it's not wrong to pick any of them. At this point, it's
individual factors that decide, and it has to be that way, because
there isn't One True Answer.
>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. [...]
>THAT'S why Lisp isn't a mainstream language.
What are these mainstream languages, anyway? C, and what else?
-- jd
Bill Birch
Once upon a time I used to use macro-processors like GPM and UNIX's
m4. I used to generate test scripts for testing X.25 and
Z80 assembler with them. These are good tools for creating ad-hoc
mini-languages.
Then somebody suggested I look at the Lisp syntax, because
is was just as adaptable (read feature-less) as m4. I did
and was immediately hooked, because Lisp has structure, unlike
macro-processors.
Since then I have used Lisp syntax to create mini-languages for a variety of
purposes including: An assembler for Finite-state machines for
a PABX configuration; for storing interactive video overlay sequences;
a language for specifying call-processing state tables; and etc...
All these have been serious industrial applications.
I particularly like being able to parse mini-langauages in a single
statement: READ. I prefer it to FORTH syntax which I did experiment
with in a protocol testing language. The structure is more obvious
in Lisp.
So as far as I am concerned, the Lisp syntax is absolutely vital, it
is what attracted me to the langauage in the first place. But
then my use of languages is driven by real need rather than by
the impositions of University lecturers :-)
[I enjoyed that!]
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...
Marco Antoniotti
In article <1k6fec$9...@agate.berkeley.edu> fat...@peoplesparc.Berkeley.EDU (Richard Fateman) writes:
Lisp is not a mainstream language, but COBOL is. Perhaps BASIC also.
(You may think C and Fortran are mainstream, but I'm not sure how
you are measuring.) COBOL is, in some ways being replaced by
"4th generation languages". Not by C or C++. Certainly not by LISP.
How come?
1. COBOL is standardized. (CL is getting that way, maybe.)
Common Lisp IS getting that way and EULISP too.
Demonstrations of superiority in a niche -- the way the 4GLs are
displacing COBOL -- may be the way to broaden the appeal of CL(OS)...
Write truly great programs in Lisp to solve important and
widespread problems -- and rely on Lisp in such a way that the
program can't be rewritten in C "to save space/time/money..".
I perfectly agree with this.
Symbolic mathematics programs like Macsyma and Reduce looked like this,
until people wrote similar systems in C (Maple, Mathematica).
But not with this second point. If you check the low level guts of
Mathematica (e.g. to interface it with some C++, Fortran or COBOL code
through the remote evaluation facilities - I do not know about Maple),
you will recognize that its core is actually.... a Lisp interpreter.
Somebody else already pointed this out. But the flame about syntax is TOTALLY
pointless. The REAL problems with CL(OS) are well known and none of them
has to do with syntax. They have all surfaced in this flame. My
personal opinio is that now there are better conditions to make CL(OS) a
more widespread language. This has happened because of a number of
historical reasons:
- CMU CL(OS) was not available until a little more than a year ago. If you
wanted CL(OS) performance you had to go to a Lisp vendor. I have nothing
against Lisp vendors, but the price difference was all there.
- WCL now addresses the problem of CL(OS) in a UNIX environment.
- Until a month ago there was NO commercial implementation of CL(OS) on
PC's at a reasonable price. (Somebody has correctly pointed out that
installing a C++ on a PC is not something that you do with two
diskettes anymore). The best commercial implementations available on PC
purportedly offer better development environment than any C++
environment on the same platform.
There are other reasons to believe that CL(OS) has now better chances than
only two years ago.
As far as I am concerned I still believe that Lisp's have some edge on
different languages as far as the programming process is taken into
account. If I must program in C/C++ I'll do it. As well as COBOL.
Having said so, I conclude agreeing with those who pointed out that
the ~R directive is too much English-centric (or English-centered ?!?
:).
I want a Swaili version of ~R in the standard.
Have a nice day
--
Marco Antoniotti
-------------------------------------------------------------------------------
Robotics Lab | room: 1219 - tel. #: (212) 998 3370
Courant Institute NYU | e-mail: mar...@cs.nyu.edu
...e` la semplicita` che e` difficile a farsi.
...it is simplicity that is difficult to make.
B. Brecht
Richard Fateman
(You may think C and Fortran are mainstream, but I'm not sure how
you are measuring.) COBOL is, in some ways being replaced by
"4th generation languages". Not by C or C++. Certainly not by LISP.
How come?
1. COBOL is standardized. (CL is getting that way, maybe.)
2. COBOL is or was a required language for US gov't procurement.
3. COBOL became the defacto standard for a commercially important segment
of the computer buying community because of 1 & 2.
4. It would be pointless to argue in this newsgroup about the relevant
syntax and semantics of COBOL vs. Lisp.
5. COBOL existed at the right time and place to fill a particular niche.
Not the niche filled by LISP, but a niche. LISP's niche is smaller,
perhaps.
How is it that people reading (or writing) here think that C is a mainstream
language?
Perhaps because they perceive that the niche for C programs is better
known and/or larger. What is that niche?
1. writing UN*X operating systems.
2. writing compilers, interpreters (including Lisp interpreters!), editors.
3. writing other low-to-middle level code that needs access to OS utilities
and should, itself, be useful as a utility (i.e. small in size).
4. (ugh) education, since some educators think that popular = good.
Some people would claim Fortran is a mainstream language (although
the number of people using COBOL totally swamps the Fortran community).
My argument here would be that there is a niche, and frankly, Fortran,
in its various versions, pretty much fills that niche as a (mostly batch)
numeric processing language.
Lisp pretty much fills its niche (competing perhaps with Prolog?, competing
amongst dialects? competing with C?)
If your idea of mainstreaming Lisp is that you should do something to
it so that it would invade other niches, I'm not sure how to do that,
but making it small/fast/efficient would make it more plausible.
Providing a front end for COBOL or a front end for C, which would
erase all syntactic or semantic differences (ugh!) does not seem like
a winning idea ...
Demonstrations of superiority in a niche -- the way the 4GLs are
displacing COBOL -- may be the way to broaden the appeal of CL...
Write truly great programs in Lisp to solve important and
widespread problems -- and rely on Lisp in such a way that the
program can't be rewritten in C "to save space/time/money..".
Symbolic mathematics programs like Macsyma and Reduce looked like this,
until people wrote similar systems in C (Maple, Mathematica).
--
Richard J. Fateman
fat...@cs.berkeley.edu 510 642-1879
Scot Dyer
;;; functions. Then if somebody needs to print checks in Spanish they can
;;; write their own routine to ha ndle the ~R directive. But even if the
;;; standard specifies the behaviour only for english, I think that
;;; thinking only "american" with respect to the "billion thing" is quite
;;; irritating. For yes-or-no-p it would be very easy (and extremely
;;; useful) to specify in the s tandard some system variables which you
;;; could modify to hold the string appropriate for the local language.
Actually, yes-or-no-p would be very hard to internationalize correctly. There
exist languages with no direct translations of the English "Yes" and "No," and
languages where the semmantics of "Yes" and "No" are quite different for
questions posed in the negative. Examples are Welsh (with no direct 1-to-1
translation for either 'Yes' or 'No'), Japanese (where the semmantics of saying
'Yes' to a negative question are different than those of English), and French
(where a 3rd word is added for disambiguating answers to questions in the
negative)
As for format's ~R, it could be internationalized, but personally I'd rather
see format dropped from the CL specification and replaced with several
functions, maybe one for the actual output and others that do formatting.
The current format defies most conventional tree-shaking algorithms. This
wouldn't be so bad if it weren't so mammoth to begin with... IMHO, of course.
I don't want to get rid of ~R, just make it its own function.
;;; And yes, I think CL is "a nice PL/1". And in the same way everybody
;;; around here seems to want everybody else to program in LISP, I will be
;;; happy only when most LISPers program in SCHEME (with a good MOP,
;;; of course). Then I could get a lot of public domain tools for it and
;;; abandon CL. If C++ is the black hole of OO programming, I must say
;;; that CL is the neutron star of list processing.
I agree that CL/CLOS/CLIM is probably too big to run as anything other than
an OS, and the design really isn't that compiler friendly. A nice, small,
OO lisp (maybe Scheme + OO or Dylan) with _libraries_ would be much more
practical.
And before everyone starts shouting that I want to remove all dynamicism from
Lisp let me assure you: I only want to remove that dynamicism that isn't
necessary for the semmantics of a given program. The compiler technology
exists for this kind of thing, but the language spec needs to be more compiler
friendly if we're ever going to see compact binaries coming from Lisp source.
-- Scot
Tom Pole
>
>>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??
>
>Well, it is fun. But from this corner of the world I suppose that it is
>a more serious problem (if not a disaster) that Common Lisp provides
>input and output functions that are suited only for English/American.
>
>(format t "~R" 4) -> four really doesn't help very much in most of the world.
I'm a bit confused. The fact that the output is in 'American' is somehow
different from the code being in 'American'. Don't 'C', Fortran, Basic, Ada
compilers' source code in all countries use "print", "open", "type",
"character", "in", "out", etc., etc. This may be a complaint, but surely
not a complaint about Lisp syntax/semantics.
I don't believe it would be terribly difficult to write a lisp extention
to allow a format method to be defined on a foreign language object
to produce the textual versions of numbers. I believe that Lisp
syntax/semantics and its dynamic/extensible nature would also make
such an extention easier to implement in Lisp than in most other
languages.
>And yes-or-no-p cannot be used either.
Thomas
>
>I do think it is a mistake to include natural language specific functions
>in a language standard.
>
>Flemming
--
Thomas Pole
Harley Davis
(Arun Welch) writes:
> I think an associated question we should be asking is "How can we
> increase Lisp's popularity"? Knowing why it isn't popular is a good
> thing to discuss, but it would also be good to know where to go from
> here. Another question is "Should Lisp be a mainstream language?" I'm
> not sure the answer to that is yes. A lot of neat ideas have risen out
> of Lisp not having been standardised to death early on. CLOS is a case
> in point. If we'd standardised on Interlisp and LOOPS or Zetalisp and
> Flavors I think we'd be a lot poorer today.
Yes "Where to go from here?" I am disappointed that the Lisp leadership is
not addressing this question. This begs for something like the Common Lisp
project but aimed at making Lisp smaller and faster in an organized way. I
was reading about a KERNEL lisp specification in Lisp and Symbolic
Computation. Perhaps something along these lines should be hit with force.
Lisp leadership where are you? Give us something to be hopeful for.
I suggest you look at EuLisp and Dylan as steps in this direction. I
would also like to humbly offer Ilog's Le-Lisp version 16 as another
member of this set of modern Lisps which attempt to address the
deficiencies and excesses of previous Lisps, although I have a certain
commercial stake in it. Also, the emerging ISO Lisp standard is much
smaller than Common Lisp while retaining the most useful features such
as a small, CLOS-like object system.
-- Harley Davis
--
------------------------------------------------------------------------------
nom: Harley Davis ILOG S.A.
net: da...@ilog.fr 2 Avenue Gallie'ni, BP 85
tel: (33 1) 46 63 66 66 94253 Gentilly Cedex, France
Harley Davis
>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.
The C language has no mechanism for this. It's the linkers that do
it.
So, the right question is: is there something about the language
that rules out implementation strategies that omit unneeded code?
And the answer is "yes". Almost anything could be called, eg by
(apply (read) (read))
So implementation either have to provide a way for the user to
say that only the functions that are directly called will be
called or else provide a way to load in functions when needed.
The latter approach has been around for a long time in the
form of "autoloading".
However, such tricks won't work very well if programs tend to
require most of CL, perhaps because CL is so intertwined. This
is a standard criticism of CL. ERROR requires FORMAT, etc.
But how true is it? Well, I think there's evidence that it's
sufficiently true to be a problem. On the other hand, why
should it be fatal. What if, for instance, CL is packaged as
a shared library (as in WCL)? It's a fairly big shared library,
but then so is X.
The problem is somewhat more complex. Another difference between Lisp
and C is that Lisp allows the creation of rather complex data at the
top-level. These data objects range from symbols to functions to data
structures stored in global variables to classes, etc. Although
shared libraries help a lot in managing code size, they do not reduce
data requirements. Even modules which have completely unexecuted code
still need to initialize their data; at a minimum, their symbols and
most likely a number of functional objects as well. There may be ways
to put off the creation of other top-level data until the module is
needed, but this requires rather complex management which has its own
cost. All this said, shared libraries are still winning. However, it
would probably be a mistake to provide *all* of Lisp as one shared
library.
I should note that C++ also has this problem to some extent since it
allows top-level data initialization and needs to initialize its
virtual function tables and other class-related hidden objects. In
fact, I don't think many C++ compilers allow the creation of shared
libraries. For example, Sun C++ has no position independent code
generation option. This may be seen as one of the biggest changes
between C and C++, and has many ominous overtones that most of C++'s
advocates don't yet understand.
Gregory Vance Wilson
>gwi...@majestix.cs.uoregon.edu (Gregory Vance Wilson) writes:
>> > jaf...@zurich.ai.mit.edu (Aubrey Jaffer) writes:
>> > Some things which could be added to SCM are:
>>
>> Some other things that might speed its adoption by the rest of us:
>>
>> * a textbook on software engineering which uses Scheme as a
>> language for its examples
>
>Scheme as its delivery vehicle: `Structure and Interpretation of
>Computer Programs,` from The MIT Press.
I'm afraid I disagree --- SICP is a wonderful book about how to program, and
think about programs, but it isn't really about managing program development
(which is what I mean by "software engineering"). It's been a while since I
read it, so forgive me if I'm off base, but I don't recall any discussion of
planning program development, managing revision control, developing test
suites and schedules, black box vs. glass box testing, negotiating and
validating interfaces, etc. If there is a book about such things which uses
Scheme as its core language, I'd be very grateful for a pointer to it.
Larry Wall
: I believe that an important point that is being lost in the shuffle is
: whether or not the language is malleable enough to provide "control
: abstraction" (analogous to the way classes, structures, etc., provide
: data abstraction). If the language cannot provide good control
: abstraction, then *it's not good enough*.
The question is, of course, good enough for what?
: (Of course, the lack of
: control abstraction does not render a language useless any more than the
: lack of data abstraction does -- it just makes life much more difficult
: than it needs to be, and really, isn't programming is hard enough
: already?)
Depends on what you trade away to get your abstraction. Abstraction
doesn't come for free. Abstraction is most appealing to those folks
who are highly intelligent. By definition, they're in the minority.
Ordinary people tend to avoid abstraction: "Forget that ivory tower
stuff, just get the job done."
People learn to love Lisp from they're instructors, fine. I'm not
saying we shouldn't try to teach people to do abstraction. But
let's not expect people to like doing what they don't like to do.
Castigating the Huddled Masses for huddling is a mild form of snobbery.
: In my opinion, almost every modern programming language fails to provide
: control abstraction. One reason Lisp manages to provide it is that the
: syntax of the language makes it easy to use Lisp as its own meta-
: language. There are other ways to do this (e.g., add features to the
: language that allow the language to talk about its own parsed
: representation),...
Gee, when you point out the upside of Lisp's narcissism, it's central.
When I point out the downside, you tell me I'm stuck in 1972.
: ...but to the best of my knowledge, there aren't any
: languages that do this in any serious way.
Thank goodness. Simplify here, complexify everywhere else. TANSTAAFL.
Your turn to have the last word.
Larry Wall
lw...@netlabs.com
Technically Sweet
as the language itself. I want a windowed browsing/control
environment written in Scheme; there are several free universal
window system libraries that could support a portable environment.
--
Lance Norskog
thi...@netcom.com
Data is not information is not knowledge is not wisdom.
Scott McKay
From: Larry Wall <lw...@netlabs.com>
In article <1993012715...@SUMMER.SCRC.Symbolics.COM> S...@stony-brook.scrc.symbolics.com (Scott McKay) writes:
: I believe that an important point that is being lost in the shuffle is
: whether or not the language is malleable enough to provide "control
: abstraction" (analogous to the way classes, structures, etc., provide
: data abstraction). If the language cannot provide good control
: abstraction, then *it's not good enough*.
The question is, of course, good enough for what?
: (Of course, the lack of
: control abstraction does not render a language useless any more than the
: lack of data abstraction does -- it just makes life much more difficult
: than it needs to be, and really, isn't programming is hard enough
: already?)
Depends on what you trade away to get your abstraction. Abstraction
doesn't come for free. Abstraction is most appealing to those folks
who are highly intelligent. By definition, they're in the minority.
Ordinary people tend to avoid abstraction: "Forget that ivory tower
stuff, just get the job done."
Of course abstraction doesn't come for free. The question is, does the
investment made in abstraction pay for itself (or make a profit) down
the road. The answer for data abstraction is a pretty clear yes, and
has been for over twenty years. Most Lisp afficionados will claim that
the answer is yes for "control abstraction" as well.
People learn to love Lisp from they're instructors, fine. I'm not
saying we shouldn't try to teach people to do abstraction. But
let's not expect people to like doing what they don't like to do.
Castigating the Huddled Masses for huddling is a mild form of snobbery.
On the contrary, assuming that the majority of programmers are "huddled
masses" is a veiled form of arrogance. I guess I just don't know what
"ordinary people" you are talking about. Surely anyone clever and
patient enough to learn C or perl can learn about abstraction, which is
after all, in its most basic and useful form, just a formal name for the
simple concept of naming or abbreviating a common idiom.
: In my opinion, almost every modern programming language fails to provide
: control abstraction. One reason Lisp manages to provide it is that the
: syntax of the language makes it easy to use Lisp as its own meta-
: language. There are other ways to do this (e.g., add features to the
: language that allow the language to talk about its own parsed
: representation),...
Gee, when you point out the upside of Lisp's narcissism, it's central.
When I point out the downside, you tell me I'm stuck in 1972.
You will probably not find many people who think that linguistic
introspection is a form of narcissism.
: ...but to the best of my knowledge, there aren't any
: languages that do this in any serious way.
Thank goodness. Simplify here, complexify everywhere else. TANSTAAFL.
Again, the burden is on you to show exactly what has been complexified.
Your turn to have the last word.
OK. Um, here, let's try this:
As an experienced assembly-language and microcode programmer and an avid
user of Teco from its PDP-10 days, I am sympathetic with your desire to
play with primitive languages, because it can be fun to hack when all
the odds are against you. Unfortunately, some people just don't have
time to indulge in that simple pleasure. They need programming
languages that allow them to write serious software in bounded time.
They need languages that allow old programs to be re-read years later
without huge effort. I no longer have that luxury, so I mostly (but not
exclusively) use Lisp. It pleases me that some people do have the
luxury of time, or never need to go back and look at their old code; let
them use Teco and C++. Or more likely they're using Cobol and Fortran
only because they have to, which is a shame.