Lisp

The real problem with Lisp is that it was designed without any consideration of the cognitive load experienced by the programmer.  The syntax may be simple, but the semantics are extremely complex and hard to master.  This is completely at odds with needs of the programmer. 

The main cognitive load is in developing a solution to the real world problem.  The programmer is engaged in reflective cognition.  Basic UI principles dictate that, when designing tools to aid in reflective cognition, they must as intellectually shallow as possible.  The less cognition required to operate them, the more is available for completing the required task.

Lisp was unintentionally designed for experiential cognition.  It contains many artifacts, each with a very deep and rich set of semantics.  All cognition must be devoted to its operation.  It is no surprise that it only attracts programmers who are only interested in using it for its own sake.

>>5

orly?

Yes, that is in fact what I typed. Congratulations on being able to read, cunt.

Why refer to speed and the ability to output efficient machine code as a language feature?

First of all, implementations are what you use to run code, unless you're content with tapping out code in emacs and not using it (since you probably don't write code, I can understand why this wouldn't seem like much of an issue to you). In the Real World ^(tm), the implementation can cripple the use of an otherwise-wonderful language (the fragmentation of Lisp (especially in the past) serves as a great example - dozens of implementations (because implementing a language is simple, LOL), none of which are complete, sane or even useful). Before you post a raging response saying that I didn't understand what you're saying, yes, I get the distinction between "specified language" and "implementation." I don't really fucking care, for the reasons I specified above and below.

This leads me to my next point: you are an idiot. I know we've all been raised in this bubble where kind-a sort-a language execution speed doesn't matter so just write your code in Ruby OMG MOORE'S LAW LOOOOOOOOOL, but it just isn't true. Some languages are poorly-implemented and slow, some aren't. None are perfect, but some are better than others. Sometimes, performance does fucking matter, and that's enough of a reason to pick a language with a decent implementation.

That is mostly implementation dependent and any language could be extended to include these features.

Your use of "implementation dependent" in a manner that implies triviality shows either that you have no fucking clue what you're talking about, or that you're a wizard interpreter/compiler designer. I have a comfortable guess as to which category you fall under.

Look, since you're obviously some slow kid who reads Wikipedia and masturbates himself with sterile, academic explanations of things, I'll spell it out for you: implementing a rich, well-designed language in a way that leads to fast code is a very complex engineering effort. Doing this on a whim is very likely to fail. Read more books, write some more code and pull your head out of your ass before posting again, especially if you're going to be snarky. I guess I'll stop making fun of you, because anyone who gets their rocks off pretending to know what they're talking about on a shitty 4chan board is probably a very sad, frail person.