
Lisp is Not an Acceptable Lisp (2006) - krmboya
http://steve-yegge.blogspot.com/2006/04/lisp-is-not-acceptable-lisp.html
======
lkrubner
Steve Yegge regarding Clojure (2012):

" For a few years I had been really excited to start learning Clojure, and my
initial experiences with it were quite positive. However, I eventually learned
that the Clojure community is extremely conservative. That is is pretty
unusual for a Lisp dialect. Lisp is widely regarded as one of the most liberal
language families in existence. And Clojure has the superficial appearance of
being a laissez-faire kind of language. It is quite expressive, including a --
ahem -- liberal dose of new syntax. And it eschews static type annotations and
strong type modeling in favor of a small set of highly regular, composable
data types and operations -- not unlike, say, Scheme or Python. But the
resemblance to a liberal language ends there. Clojure's community came pre-
populated with highly conservative programmers from the pure-functional world:
basically Haskell/ML types (lots of puns today!) who happen to recognize the
benefits of Lisp's tree syntax. So under its expressive covers, everything
about Clojure is strongly conservative, with a core overriding bias towards
protecting programmers from mistakes."

[https://plus.google.com/110981030061712822816/posts/KaSKeg4v...](https://plus.google.com/110981030061712822816/posts/KaSKeg4vQtz)

He defines conservative:

"I hope you'll agree that this definition is minimally controversial. After
all, the adjective "conservative" is more or less synonymous with caution and
risk aversion. Financial conservatism is frequently (and intuitively)
associated with age and with wealth. "

My own feeling is that he misunderstands functional programming. I could say
"functional programming offers safety from side-effects" and then he might say
"Yes, that is what I mean by conservative" but who wants to have their code
undermined by uncontrolled side effects? By his definition, "conservative"
applies to every programmer; which makes me think his definition is useless.

~~~
agentultra
Side effects are useful. We use them all the time: IO, graphics, sockets,
signals, etc. We even use mutable data because in certain cases it's more
efficient. So I think I agree with Yegge there wrt, "conservative."

~~~
codygman
Not sure if it was your intention to imply so, but neither Clojure nor
Haskell* eschew side effects. However Haskell provides tools to manage side
effects. I'm not sure about Clojure since I haven't dove into that pool yet.

* I mention Haskell since there is a lot of FUD going around about Haskellers not using side effects.

------
kabdib
When I first read Guy Steele's 2nd edition of _Common LISP, the Language_ in
the early 90s I remember thinking "This is a huge language, how could anyone
implement this reliably?"

A recent pass through that book, and the language actually seems small. Not
trivial, but definitely doable by a smallish group of people in a reasonable
amount of time. Implementing a browser DOM plus JavaScript, or a C++ compiler,
seems a lot more daunting.

------
andrewflnr
I wonder to what extent this is still true with Clojure picking up steam. It
doesn't have the old-Lisp roots sticking out, but replaces them with
protruding Java bits[0]. Plus I seem to recall Steve wanted Clojure to "say
yes more" (can't find the link now), but don't know if he still feels that
strongly.

[0] I have only done a little bit of Clojure programming, but I remember being
mildly frustrated by having to deal with unfamiliar Java-isms that were
showing, not having done Java at that time. This was around a year ago.

------
xpe
For me (and lots of other people, too) Clojure is a fantastically acceptable
flavor of LISP.

~~~
WildUtah
Racket has become a pleasant and acceptable, modern, batteries included Lisp
as well.

Now our cup runneth over. Common Lisp is the same as it was while Clojure and
Racket offer ways to a lispy future.

~~~
eudox
>Common Lisp is the same

But the great thing about Lisps is that they can't get stuck in the past.

For example, if, say, Python didn't have decorators and you wanted to add them
in, you'd have to present the idea in a PEP, get approval from Guido, write
some code, et cetera. In Common Lisp, you just write some reader macros and
that's it[1]. If Python stopped being maintained, it would lag behind other
languages, but the fact that the Common Lisp spec hasn't been updated since
1996 doesn't make it any less modern.

A more relevant example: Lisp doesn't have hash table literals, which every
"modern" language these days has, but those can also be added, trivially in
less than fifty lines[2] of CL code, and suddenly Common Lisp is modern again.

[1]: [https://github.com/arielnetworks/cl-
annot](https://github.com/arielnetworks/cl-annot)

[2]:
[http://frank.kank.net/essays/hash.html](http://frank.kank.net/essays/hash.html)

~~~
PeterisP
In programming languages, having 3 proper solutions to a problem is worse than
having a single proper default solution - simply due to the overhead of first
having to choose, and then the unneeded difficulty when reading other people's
code who chose a different lib for the same thing.

For things such as hash table literals, you're not supposed to simply have
some way of doing it - you're supposed to have a good and commonly used way of
how most everyone else would be doing it and representing them in his/her
code. Having a bunch of nonobvious, nonstandartized ways alone hurts
readability, maintenance and reusability - and thinking that it is okay is a
sign of being stuck in the past.

Being able to add it trivially yourself is an order of magnitude worse -
because results in everybody rolling out his own. If you want to make an
usable ecosystem (not just 'language core') then you have to make sure that
for all/most commonly needed things, the default 'batteries included' or
'batteries taken from first google result' work well, not that it's simply
possible to get them somehow.

------
mappu
_> Once you've got a canonical AST defined, syntax should, in theory, be like
CSS chrome_

This is an awesome idea. Are there any projects working on this concept? I
guess multiple languages targeting the same bytecode is as-close-as-practical
at the moment.

~~~
voyou
AIUI, this was the original genesis of Lisp - the S-expressions were supposed
to be an internal abstract representation, and programmers would write
"M-expressions" in a language a bit like Fortran. But everyone involved in
Lisp realised you could just write S-expressions directly, and never got round
to defining the M-expression syntax.

More recently, the GNU scheme project, Guile, had people working on pluggable
syntax translators that would allow you to write Guile programs in TCL or
JavaScript syntax, but AFAIK that project never produced anything completely
usable.

------
chimeracoder
Sigh. This blog post again.

At least it's been posted with the "2006" date in the title, but some of the
problems:

1\. The title is catchy and provocative, but it should really read "Common
Lisp is Not An Acceptable Lisp". "Lisp" by itself is a family of languages,
not a single language. Most of the blog post is dedicated to attributes of
Common Lisp specifically. The title always struck me as a bit disingenuous and
link-baitey, especially since his _very first point_ is about how there are
multiple different Lisps.

2\. _Which_ implementation of Common Lisp are you talking about? There are
several, and when you talk Haskell "kicking its ass all over the performance
map" because of the type system, it's helpful to know whether you're talking
about CLISP (an interpreter by default), or SBCL (a Lisp compiler, and one
that is highly focused on speed.)

3\. CLOS looks weird to people who are used to "object oriented" languages
like Java, sure, but it's much more true to the nature of object-oriented
programming as a whole. I'll refrain from pulling out the old Alan Kay
quotation in which he (the father of the term "object oriented") identifies
Lisp and Smalltalk as the only two OO languages that he's aware of, but CLOS
is _much_ more true to the spirit of OO programming than any other system I've
worked with (except perhaps Smalltalk)[0].

4\. "There is no acceptable Lisp". In 2013, this is utter nonsense. I'll give
Yegge the benefit of the doubt when it comes to 2006, but even still, it's
rather frustrating to read 3000 words (yes, I counted) about the shortcomings
of Common Lisp, and then suddenly the author jumps to the conclusion that
_all_ Lisp dialects are equally bad, with no supporting evidence.

I have my fair share of frustrations with Common Lisp. The spec shows its age
in many ways, and I really wish it had a number of features that I like about
modern Lisp-like languages like Racket[1] - dialect scoping, hygenic macros,
optional typing, etc.

But I cringe when I see links to this post in 2013. For a blog post that's so
long, it's surprisingly spare on evidence that supports the argument presented
in title or the conclusion, even if it gets a number of things right along the
way.

[0] As pointed out below (thanks, cwzwarich), Kay's quotation mentions Lisp
(not CLOS by name), so it's a jump for me to assume that it implies his
support of CLOS specifically. That said, if you implemented OO-programming (as
_Kay_ defined it, not as _Gosling_ defined it) in Lisp in the most
straightforward way possible, you'd end up writing something that resembled
CLOS.

[1] I say "Lisp-like" to pre-emptively deflect any debate over whether or not
Racket is a "true" LISP (it certainly isn't a true Scheme, because it is not
fully compliant with any single Scheme standard; it uses a hybrid of R5RS and
R6RS)

 _EDIT_ : Okay, here's the Kay quotation: "OOP to me means only messaging,
local retention and protection and hiding of state-process, and extreme late-
binding of all things. It can be done in Smalltalk and in LISP. There are
possibly other systems in which this is possible, but I’m not aware of them. "
([http://userpage.fu-
berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...](http://userpage.fu-
berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en))

~~~
acchow
> "OOP to me means only messaging, local retention and protection and hiding
> of state-process, and extreme late-binding of all things. It can be done in
> Smalltalk and in LISP. There are possibly other systems in which this is
> possible, but I’m not aware of them. "

Excellent quote. He correctly omits _types_ from his description, yet OOP is
typically taught (especially in school) as a system of types. We're being
dishonest when we say "object oriented" when we really mean "class oriented".

~~~
vezzy-fnord
It's not just in schools. It's more a consequence of the fact that the vast
majority of mainstream languages use the Nygaard model class-oriented
incarnation of OOP, rather than Kay's model of messaging.

------
lispm
The same Yegge implemented JavaScript in Emacs Lisp...

------
nnq

        Just have to say it: Clojure *is* an Acceptable Lisp

------
kelvin0
It's funny how 'older' articles submitted to HN get a second (third?) wind.
Why? Why? Why? Is this a slow day?

~~~
justbaker
Yeah bro it is. I'm bored, browsing HN, seeing articles I've already disliked.

The article seems to blame the programming language for the issues cause by
the social involvement of the community.. and laziness to research and find a
good environment to develop with.. come the fuck on. If you're a programmer,
you're a problem solver. Don't bitch about solving one..

Funny how this ^ is still... 7 years later.

------
GarvielLoken
I really don't like this authors way of writing. His only valid success
criteria seems to boil down to something similar in meaning of "An acceptable
lisp is a lisp that every single programmer uses it".

1\. "Killing adoption"? For what goal? People have different thought process,
each dialect will be more natural for a certain subset of people. Offering
dialects and diversity in choice is a good thing. I have only limited
experience, last semester when i graduated i took a SICP course and now i have
read through On Lisp because i thought macros sounded powerful, so i am going
to be programming a hobby project in Common lisp. But that doest mean i want
Scheme to disappear from the world.

2\. Libraries.

3\. I haven't used CLOS much so i can't really say anything. But making
complaints that things are "bolted on" Common Lisp because of the macro system
seems to me that he has missed the point of what people like with Common Lisp
and its macro system.

4\. Can't one use Scheme if one wants portable hygienic macros? I can agree
somewhat with the macro situation and my own research seems to point this to
the historical decision to pass on fexprs to gain efficient compilers. The
plus side is that macros can expand macros means is generally works. And i
don't get this "band-aid" notion. From what i understand macros are argument
to use lisp and should be utilized.

NewLisp offers fexprs and is focus on interpreted, which means that at any
time you have access to a functions definition to use for self-modifying code
and eval is blazingly fast compared to other lisps that support compilation. I
want to start experiment with true ai that can modify its behaviour in newLisp
soon. This is also an argument on point 1 of the diversity of lisps. ( yet i
guess you could in common lisp use a macro that always saved the interpreted
function definition in some global has that you could operate on in a macro
dsl )

On a closing note i would like to add that it isn't really important to
attracts people to lisp. Infact from an ethical standpoint trying to sway
people which tools they "need to use" is questionable. And in a similar spirit
of the HN article "People don't like creativity" i am not convinced that
everyone actually would prefer lisp even if we lived in a world where lisp
were as popular as C# and Java together.

Every programmer will hear about lisp at some point and if they are interested
in it they will probably explore it.

------
yarou
Haha, I remember reading this back in the day. While I came from a primarily C
background, I have to say that Clojure truly is not only an acceptable lisp,
but a refreshingly "modern" language -- in the same sense that Algol was a
modern language for AI researchers. It packages cutting edge features, like
STM, without necessarily complicating certain abstractions.

