[WinterAyars]

The whole point is that there's more to languages than just "technical correctness". Lisp is great technically and theoretically, but in other respects it is quite a ways behind (for instance) Ruby. So Ruby has some big problems (speed, to use everyone's favorite example) but just saying "Ruby is slower so we should all use Lisp" is a bit ridiculous. That's what he was trying to say.

(He's also not a native English speaker, so i cut him some slack on that front.)

[lispm]

I was not talking about 'technical correctness' (though the literature how to implement languages does exist - just start with Steele's papers - Steele describes efficient compilation some thirty years ago), but about 'technical capabilities' - and it that area Ruby is lightyears behind Lisp implementations. I'm also not saying 'Ruby is slower so we should all use Lisp', I'm saying: Ruby is much less capable than Lisp, so it neither is a Lisp nor is it able to replace Lisp for the tasks where people use Lisp. For an expert Lisp programmer there is little reason to use Ruby anyway. Ruby has a larger user community, but that does not help me when Ruby simply does not provide the capabilities I need - the user community could be ten times larger and the number of libraries could be also even larger. It does not help if the libraries that I'm interested in are not available and probably never will.

Matz designed Ruby for so-called 'ordinary' people with him to do the language design. I can tell you for sure that I neither like his design nor do I want him as the language designer. In the Lisp world the implementors role is to empower the user, not make them dependent. I need a new control structure? I write one myself. I don't have to wait for some benevolent dictator, who probably does not get basic designs right - just look at the confusion of blocks, lambdas, etc. in Ruby.

(also there is no excuse for putting confused stuff on slides, even when he is not a native speaker - lots of people (including me) are no native English speakers and I haven't sensed this amount of confusion Matz shows)

That Lisp is too complicated for some people is not news, still Emacs (which he tried) now comes with a standard library of a million lines of Emacs Lisp code for all kinds of editor extensions. Emacs Lisp code that has been written by very different people and obviously a lot of them learned enough Lisp to write sophisticated applications based on Emacs (like GNUS, calc, the various mail modes, org mode, ...).

Lisp is also not only great technically and theoretically, but some people found it practically. There weren't ten maintained Common Lisp implementations if there were no users for it. For example the talks at the Lisp Meeting last sunday here in Hamburg described several applications in Lisp: an airline reservation system (developed by a team of hundred people, fifty of them Lisp programmers), a visual reactive programming system, an aircraft analysis tool, a reasoner for the semantic web, a visual simulation system, machine learning applications and some more.