
Steve Yegge: Lisp is not an acceptable Lisp. (2006) - steiger
http://steve-yegge.blogspot.com/2006/04/lisp-is-not-acceptable-lisp.html
======
lispm
it is still Yegge: shallow and mostly wrong.

People who actually use Lisp (opposed to people who only write about it) have
no problem that there are extensions to the standard. The whole point of Lisp
is that it is easily extended in many ways: the programmable programming
language. Sure it brings a bunch of problems, but that's what it is and why
people use it.

The stuff he writes about CLOS is mostly wrong. CLOS is not implemented as a
bunch of macros. CLOS is actually a three level architecture: the core is
written object-oriented in CLOS itself, on top is a functional interface and
for user convenience there is a bunch of macros for easy definition of
classes, generic functions, methods and some other language objects.

Then, macros are no problem. They are a feature. No, 'hygienic' is fine, but
not needed. No they don't need to be rethought. They do a useful job like they
are.

No, Lisp will never be massively successful (because it is a bit too
complicated, too dynamic, too powerful for many users) and bending the
language trying to make it 'massively successful' won't improve anything. No,
I don't want a dictator. Lisp has choice, various alternatives and a more
democratic approach.

Lisp is still a good choice for computing with symbols. If you don't need
that, then you might not need Lisp. But that's not a reason that Lisp should
change. Should a helicopter be changed in design because someone does not use
it, but drives a car? Should the helicopter be changed, because more people
drive cars, getting a drivers license for cars is easier than getting a
pilot's license for helicopters? Lisp is different, for a reason and this
difference will ensure its survival for many years. We have now fifty years
that the basic ideas have proven to be useful and I don't see that this will
change in the coming years.

~~~
berntb
>>Lisp will never be massively successful (because it is a bit too
complicated, too dynamic, too powerful for many users)

I have a hard time buying your explanation, since the scripting languages of
today can be described as lisp subsets.

I am a fan of Perl and enjoy my life. The other usual scripting languages are
quite similar, in most ways.

Still, I'd love to get a job using Common Lisp, which I haven't really touched
since I studied. Why can't I do that?

Edit: I don't mean to whine, it is just that there is something wrong here.
Lisp should be a, well, "contender".

~~~
WinterAyars
Try listening to Matz talk about his experience with Lisp and (subsequently)
his inspiration to make Ruby. Basically, he said Lisp sounded great in
theory... but actually when you have to use it it's a huge pain in the ass.
And Matz is a pretty fucking smart guy, so it's not just that too many people
are too stupid to use it. Lisp actually has problems. But nobody is willing to
talk about them.

(I'm trying to hunt down that talk, but not having much luck.)

~~~
lispm
I saw that talk and I can tell you that he looked very confused. He was just
in the need for an excuse to develop just another scripting language. You
could see that he had not much experience with Lisp and that Lisp was not
something that he actually needed. I think he knew Lisp mostly 'in theory'.

If you think that he is a pretty smart guy, then I would say that there are
many Lisp implementations that are way ahead in terms of implementation
technology - Matz's Ruby implementation is in the Lisp world several decades
behind the state of the art. Ruby is one of the slowest scripting languages
and has a very much ad-hoc design. It does useful things for many people, and
that counts. But from the technology it is Ruby that is a huge pain in the
ass. Just see how people struggle to write a decent compiler for it. Instead
it is just another simple interpreter with a C core for the interpreter
implementation and parts of the library. Ruby is fast where you stay in with
the library functions that are implemented in C - otherwise it is a pain.

The better Lisp systems are also written in Lisp and their performance is
sometimes 10 to 100 times of what Ruby offers - while Lisp offers also lots of
dynamic features and the code as data paradigm.

~~~
WinterAyars
If you did, indeed, see the talk then i think you missed the point.

~~~
lispm
<http://rubyconf2008.confreaks.com/matzs-keynote.html>

He sounds confused.

Started with BASIC: 'I could Make Intelligence'. ???

Then he found Lisp in a magazine article and 'fell in love with it'. 'BASIC
aristocracy' vs. 'Lisp democracy'???

He liked Lisp from a book, but 'unfortunately he did not have a computer that
could run it'. In University he used Emacs Lisp and it did not make him
'happy'. Parentheses? No? He had no problems with it. Macros? Partially.
'Smart people just underestimate oridinarity (sic) to use Lisp'. 'We are too
ordinary to use Lisp'. Aristocracy. He is happy with aristocracy, as long as
he has power.

The whole video is so painful...

~~~
WinterAyars
The whole point is that there's more to languages than just "technical
correctness". Lisp is great technically and theoretically, but in other
respects it is quite a ways behind (for instance) Ruby. So Ruby has some big
problems (speed, to use everyone's favorite example) but just saying "Ruby is
slower so we should all use Lisp" is a bit ridiculous. That's what he was
trying to say.

(He's also not a native English speaker, so i cut him some slack on that
front.)

~~~
lispm
I was not talking about 'technical correctness' (though the literature how to
implement languages does exist - just start with Steele's papers - Steele
describes efficient compilation some thirty years ago), but about 'technical
capabilities' - and it that area Ruby is lightyears behind Lisp
implementations. I'm also not saying 'Ruby is slower so we should all use
Lisp', I'm saying: Ruby is much less capable than Lisp, so it neither is a
Lisp nor is it able to replace Lisp for the tasks where people use Lisp. For
an expert Lisp programmer there is little reason to use Ruby anyway. Ruby has
a larger user community, but that does not help me when Ruby simply does not
provide the capabilities I need - the user community could be ten times larger
and the number of libraries could be also even larger. It does not help if the
libraries that I'm interested in are not available and probably never will.

Matz designed Ruby for so-called 'ordinary' people with him to do the language
design. I can tell you for sure that I neither like his design nor do I want
him as the language designer. In the Lisp world the implementors role is to
empower the user, not make them dependent. I need a new control structure? I
write one myself. I don't have to wait for some benevolent dictator, who
probably does not get basic designs right - just look at the confusion of
blocks, lambdas, etc. in Ruby.

(also there is no excuse for putting confused stuff on slides, even when he is
not a native speaker - lots of people (including me) are no native English
speakers and I haven't sensed this amount of confusion Matz shows)

That Lisp is too complicated for some people is not news, still Emacs (which
he tried) now comes with a standard library of a million lines of Emacs Lisp
code for all kinds of editor extensions. Emacs Lisp code that has been written
by very different people and obviously a lot of them learned enough Lisp to
write sophisticated applications based on Emacs (like GNUS, calc, the various
mail modes, org mode, ...).

Lisp is also not only great technically and theoretically, but some people
found it practically. There weren't ten maintained Common Lisp implementations
if there were no users for it. For example the talks at the Lisp Meeting last
sunday here in Hamburg described several applications in Lisp: an airline
reservation system (developed by a team of hundred people, fifty of them Lisp
programmers), a visual reactive programming system, an aircraft analysis tool,
a reasoner for the semantic web, a visual simulation system, machine learning
applications and some more.

------
andreyf
It's always bothered me how imprecise we are with words as computer
scientists. Lisp is not a language in the sense that Python or Java is. PLT
Scheme is much (much!) farther from elisp in feature sets than Python is from
Java.

The only thing unique to Lispy languages (and really _not_ at all that hard to
understand) is the language syntax and the way the compilation rules are late-
bound. That is, the compiler is intended to be extended by the user. Roughly,
you're intended to be able to say "unless (...)" will translate to "if
(!...)".

The rest of the design decisions made aren't even that outlandish: you still
have text which is parsed and either interpreted or compiled into machine
code, which is run. More foreign (and interesting), I think, is the research
being done at Alan Kay's lab now:

<http://piumarta.com/software/cola/>

------
jimbokun
"My prediction: someone will get tired of waiting, and they'll Torvalds Arc
into obsolescence before it's ever released."

This is what Rich Hickey did with Clojure, more or less. So this was a pretty
accurate prediction.

~~~
fogus
I wrote a blog post about this very thing about 6-7 months ago:
[http://blog.fogus.me/2009/02/06/yegge-clojure-arc-and-
lolita...](http://blog.fogus.me/2009/02/06/yegge-clojure-arc-and-lolita-or-
days-of-future-past/)

------
felideon
Don't miss Pascal Costanza's opinion in the comments, to put things in
perspective from an expert Lisper:

 _My impression is that you [haven't used] neither Common Lisp nor Scheme on a
regular basis, and/or in a considerably sized software project. Most of the
issues that you mention are "academic", in the sense that they are theoretical
problems which tend not to bite you in practice_

~~~
kmcgivney
I am particularly amused by this guy's ranting about hygiene and macros. I
have written quite a bit of lisp, and debugged plenty of macros, and once you
have some experience with gensyms you really don't look back and wish there
was a hygienic system.

~~~
varjag
Hygienic macros are a bigger deal in Scheme, where everything is conflated
into single namespace (you know, the land of LST). His rant about macros and
namespaces is a good hint he didn't practice Lisp that much.

------
mgrouchy
I wish he still wrote this blog.

~~~
dunk010
I really wish that he did too. Seems that All the negative comments made it
not worthwhile which is just a damn shame because the rest of the world has to
lose out now.

~~~
mgrouchy
I was hoping he would have done what other controversial(Zed Shaw) and not so
controversial(Joel Spolsky) blog authors have done and just turn off the
comments and moved on, rather than shut it down.

However, he is not indebted to us to keep writing so my opinion doesn't really
count in that regard.

------
raganwald
An interesting follow-up: Eric Kidd on "Why Ruby is an Acceptable Lisp"

<http://news.ycombinator.com/item?id=825809>

~~~
kmcgivney
The OP was a followup to the article you cited. Is that what you meant to say?

~~~
raganwald
I meant to say what I said, but I like what you said as well :-)

------
moscoso
This article was published in 2006. Why is being posted again?

~~~
zachbeane
Don't worry, it will soon grow a (2006) in the title, so people will know it's
obsolete.

~~~
raganwald
With respect, _old_ is not synonymous with _obsolete_. I find this especially
ironic since we are talking about a post written less than half a decade ago
talking about a language invented more than half a century ago.

Of course, if you feel that the post is obsolete due to progress made in Lisp
since the post was written, I'm extremely interested in hearing how things
have changed.

~~~
moscoso
The article does not mention clojure, which is an acceptable Lisp.

~~~
andreyf
Clojure is _not_ an acceptable Lisp. It's a step in the direction of Lisp from
Java, but is a step backwards from most other Lisps.

~~~
jamesbritt
How so?

I've been pondering Clojure as "Lisp with Java libs! Hooray!", but if there
are notable flaws in its Lispiness I'd like to hear about them.

~~~
jon_dahl
I think the common complaint is that that it isn't really Lisp all the way
down - it's Lisp syntax that drives the JVM. Therefore, it is a False Lisp; it
dresses like Lisp, and convinces the unwashed that it's Lisp, but it's
actually leading us astray.

See <http://www.loper-os.org/?p=42> for more.

~~~
andreyf
_it's Lisp syntax that drives the JVM_

See, this wouldn't bother me so much if it assumed the user knew the JVM
instruction set and built up abstractions around it. But no, that's not what
it does. It creates another "language", meaning "obscuring abstraction" that
_isn't_ friendly to inspection.

