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.

>>1
but the semantics are extremely complex and hard to master.
In (f . a), f is a function, it is evaluated, a is a list of arguments, they are evaluated and applied to f.
(lambda arg-list . body) makes a procedure.
Everything else can be built on top of that.

Shit that was so difficult!

>>3
There's no perfection, CL has flaws, Scheme(s) has(have) flaws, OCaml does too.
The deal with Lisp is parentheses: macros, structural editing, no ``wasn't there some magic syntax to do that?''