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...)
> "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".
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.
> 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.
I think he was referring to Lisp in general in that quotation, not CLOS, although I remember glowing praise from him regarding The Art of the Metaobject Protocol.
This is how i remembered it too. I thought he said something along the lines of lisp and smalltalk are the only two languages i am aware you can do OOP in. I tried to find this and couldn't.
And OOP here means these two things from Kay:
(i)'In computer terms, Smalltalk is a recursion on the notion of computer itself. Instead of dividing "computer stuff" into things each less strong than the whole--like data structures, procedures, and functions which are the usual paraphernalia of programming languages--each Smalltalk object is a recursion on the entire possibilities of the computer.'
(ii) "Four techniques used together--persistent state, polymorphism, instantiation, and methods-as-goals for the object--account for much of the power."
> each Smalltalk object is a recursion on the entire possibilities of the computer.
So it's like a lambda expression. Except that:
1. OOP was invented 35 years later.
2. OOP is not based on the mathematical concept of the function, which is (arguably) the most successful idea ever dreamed up by (not as arguably) some of the smartest human beings ever to live.
3. Objects are lies. An object that calls itself a COW is not a cow; a function that calls itself SEND-COWS-TO-MONTANA really does send the cows to Montana.
I'm curious why "an object that calls itself a COW is not a cow" yet "a function that calls itself SEND-COWS-TO-MONTANA really does"? Both are merely abstractions over ideas, no? One over the idea of a thing, one over the idea of doing something.
I think the idea is that domain logic is encapsulated in functions, while the objects themselves only contain metadata. So if you have an class of objects named 'COW', then the objects themselves will contain information about cows. If you simply delete the object, the cow will still exist.
However, if you run a function called, "slaughter_cow", then that should actually do something, maybe it will mark that cow for slaughter. Running functions should have real-world effects, directly manipulating data objects won't. (except maybe to cause confusion)
But this really just falls into the "no true Scottsman" fallacy, doesn't it? I mean, running a function called "slaughter_cow" that will only "mark that cow for slaughter" it is misnamed in some sense. Same for any function. Unless what you are doing is fully abstract in the first place, than any abstraction over it will in many senses be a lie.
>3. Objects are lies. An object that calls itself a COW is not a cow; a function that calls itself SEND-COWS-TO-MONTANA really does send the cows to Montana.
Err, no it doesn't. Both are manipulating symbols (names), not actual cows.
That's how we can have games like Sim City that don't cost trillions of dollars to play.
The amount of work which Racket people put into hygienic macros in the recent years gave effects. If by "controversial" you mean "less expressive" or "less composable" then those controversies should disappear already.
On a side note, it's impressive that language implementors write such a large amount of papers for almost all new language features. Compare it to the usual one-line point in changelog. This makes Racket foundations incredibly solid and learning it in depth easy and satisfying.
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...)