From: Skef Wholey
Subject: Common Lisp, flaming, and other nasty things
Date:
Message-ID: <562@PT.CS.CMU.EDU>
JJacobs began this discussion with an inflamatory article saying, among
other things, that the Common Lisp design committee was like a bunch of
spoiled, screaming children, and that Common Lisp has led to the demise
of commercial AI and Lisp programming in this country. I replied,
arguing that this wasn't really the case, that there were some fairly
complicated issues surrounding the design of Common Lisp and the current
state of commercial AI.
Now, after lobbing a few salvos back and forth, and having a little fun
with the time-honored netnews ritual of character assasination, I think
we might have a chance at actually discussing these things, because I
think I finally see where JJacobs is coming from. I think I now see his
point of view, which was somewhat obscured by the epileptic structure of
his messages.
Common Lisp was a comprimise, and it looks that way. I freely admit
that. The same can be said of the US constitution (Electoral college?
What a silly way to elect a President!) and the US government in
general. But these things work, and some of us believe that a standard,
albeit an ugly one, is better than no standard. JJacobs (I think)
believes the opposite, that having no standard would be better than
being stuck with Common Lisp. That's a fine point of view -- I can
respect that, though I disagree. Another point of view (which maybe he
holds, and certainly Hedrick holds) is that Common Lisp should have been
something else, something smaller. This, for better or worse, didn't
happen. I am somewhat more sympathetic to this latter viewpoint, but
what's done is done. If all those believing this were to get together
and design a language, I think they would find it a hard task. I
sincerely wish you luck.
>The "father of Common LISP" quote is from Lucid's latest round of advertising;
>maybe if you read something besides your own code and the network, you'd
>be aware of such things.
I read a great deal besides code and netnews, some of it even having to
do with Computer Science, but I must admit I don't spend a lot of time
perusing, memorizing, and believing advertisements in trade rags.
>The fact that Lucid is making a profit from CL does not make it commercially
>viable; take a look at how well LMI and Symbolics are doing. Also, try to find
>out just how much TI is making from the Explorer series. Take a look at
>what has happened to Inference, Carnegie and Intellicorp. Not to mention
>poor Xerox.
This, as I argued before, is more a result of the development of
low-cost high-performance "stock" hardware (e.g. Sun-4) than the
development of Common Lisp. The Common Lisp designers were foresighted
enough to design the language so that implementations on such stock
hardware could be reasonably efficient.
>As I point out, and you ignore, there is little demand other than from the
>military/academic arena, which is pretty well saturated at this point. I suggest
>you stay at CMU; the job market for Lisp programmers is pretty tight these days.
Well, gosh, I was away from CMU for fourteen months (on a leave of
absence from grad school) working as a High Paid Lisp Wizard in
Cambridge, at a company that right now has about an even mix of Suns and
Lisp Machines, doing system development in both C and Common Lisp. That
company has non-government, and soon perhaps non-US customers. I'm not
locked in an ivory tower.
>I see; the enormous cost of developing and delivering in Common Lisp have
>nothing to do with this. These syntax and semantics of other languages
> are simply better suited to this type of work.(???!?!?)
No, but if you have a program to write, and you know how it should do
what it is supposed to do, it often doesn't make that much difference
what language you write it in. Companies are delivering C-based "AI"
products not because "Common Lisp sucks," but because they don't need
all the power of Common Lisp. That power costs something, and it would
cost something in any dialect of Lisp. For C, this cost is about zero,
because practically everyone has a C compiler.
>Summing up your arguments, if cost, maintainability and portability are so
>desireable, everybody should use C instead!
No, they should use the language that's appropriate, given all the
constraints.
>> If all had
>>proceeded undisturbed, there might be several beautiful Lisps by now,
>Sounds better than one big ugly Lisp!
Writing programs in an elegant, non-standard dialect would not improve
portability. That's the point. If your point of view is that lack of a
standard would be better than the Common Lisp standard, this doesn't
help your argument.
>Charles Hedrick writes:
>>I'd like to see a Lisp which is practical to
>>use for things other than large AI programs running on huge machines.
>I agree with Mr. Hedrick; it's a dream that I've tried to promote for going
>on 15 years. But apparently it won't happen in this country. Perhaps the
>Europeans will succeed. Think of Common Lisp as the gas guzzling, chrome
>behemoths produced by the American auto industry...
Small computers are getting bigger all the time, and becoming more
capable of running Common Lisp. How about this: Common Lisp is not a
car (or a cdr!), it is a track to be run. Small machines are getting to
the point where they can run this track fast enough to make them
competitive. I think it would have been a mistake to design a language
to fit the constraints and limitations of late-70's hardware
techonology.
>Personally, I don't really care whether some (large) portion of the LISP community
>wants to saddle themselve with CL, but the drive to make it a standard ensures that
>it will remain a researcher's language.
Then the commercial world won't have to worry about it, and they can
develop something better. Right? Maybe. One thing to keep in mind is
that research does happen in industry. And large programs have been
ported from their experimental Lisp form into a "productized" C form. I
was involved with such a port myself. Not too terrible if you've got
the right tools, and/or write some of the code with that port in mind.
>LISP will not go into space;
And it's not clear that it should. What advantage do you see Lisp-based
systems having over Ada-based (or C-based, or whatever) systems in that
context? Things can't go wrong in space. The amount of effort testing
space software so totally dwarfs the development of that software that
the programming language chosen (most often assembly language, so that
scarce hardware resources are most effectively used) doesn't make that
much difference. It is no easier to assure that a Lisp-based system is
entirely bug-free than it is any other kind of system.
-- Merry Lisping, Christmas-ers,
Skef (I see no "r" here) Wholey