I don't see how Ruby could be called a Lisp.
To me, the fundamental concept of Lisp is that the basic data structure is the cons-pair, and that both code and data can be represented and manipulated as graphs of cons-pairs.
The blog is arguing that Ruby is an acceptable alternative to Lisp, which may be true. But that doesn't make Ruby a Lisp.
Its lambdas don't even close over lexical state, so I'm not sure why they even exist. Yet another concept the PHP designers don't get, I guess, but feel pressured to add. (See also: PHP's object system.)
Interestingly enough, one of Clojure's selling points is that the basic data structure is not the cons-pair (rather the implementation details of storage are abstracted). It is clearly a lisp, however.
This is so wrong in so many ways, but I think the ur-mistake, the one that leads to all the others, is writing an article like this in the first place. You like Ruby? You like Ruby. Use it! Why write a whole article trying to justify how you feel? It's as if the author is trying to give himself (and others) permission not to use Lisp.
He is saying something. Something false, I believe, but not meaningless. There is a certain style of programming that was once only possible in Lisp. The author is claiming that you can program that way in Ruby, or close enough.
Oh, I don't think it's meaningless, just that the arguments are bad, and seem to have been invented in order to justify something that doesn't really need justifying.
Now I suppose someone is going to ask me what arguments are bad. Two examples: 1. "The most common use of LISP macros is to avoid typing lambda quite so much" - obviously false; 2. Using Lisp to model a Ruby example of "mini-language" demonstrates Lisp's power, not Ruby's.
Suppose you're right. He is trying to give himself permission to not use lisp, so he feels better. Then writing this helps him use ruby (as you advise). so it's good that he wrote it. (but no need for you to read it).
No offense but I think a great deal of hacker news fans have seen this one way or the other. I remember there was response to this called lisp is an acceptable lisp. If you want lisp and are using ruby why not just use lisp? If you want ruby but use lisp just use ruby. It doesn't matter which programming language you express your ideas in. It only matters if you actually get cracking and implement your ideas. Pointless saber rattling about programming languages is quaint and dandy if you aren't actually programming. To quote feynmann "If I were forced to sum up in one sentence what the Copenhagen interpretation says to me, it would be 'Shut up and calculate!"
Humm... I still think the problems with the platform are about an order of magnitude greater then the problems with the language per se. You first need to have something to work with, and only after that you can think about improving it.
Reading the comments on that blog entry, I can't help but think Lisp is Blub. The Lisp users posting there simply can't comprehend that anything is wrong and have no tolerance for anyone who says anything is.
I misread yegge. lisp isn't a popular language its more of a language where you either use for industry or you use for experimentation or both. I personally think it doesn't matter what you code in blub or not blub it just doesn't matter. What matters is if you ship or not.
An accessible, easy-to-learn lisp platform with a full complement of libraries
PLT Scheme? Clojure?
Even CL has some of the best libraries I've used, although coverage can be spotty at times.
This still hasn't killed all the other programming languages, which leads me to believe that libraries aren't actually what matters. I think, instead, that most people pick programming languages based on what's crammed down their throats. For a UNIX app, you "have to" use C. For everything else, you "have to" use Java, since that's what you learned at school (now it's .NET too).
Popularity is overrated anyway. Haskell and SBCL are not exactly popular, but they have great runtimes, important modern features, and plenty of libraries and tools. The only reason not to use them is because you'd rather use Java instead.