| > Modern Schemes are fully as production-ready as CL. Modern Scheme still doesn't have hash tables (c.f. R7RS[1]; of course Lisp has them). That, right there, prevents it from being a production-ready language. I could omit the rest of this post and I'd be right. Scheme does have continuable exceptions, but it's still a far cry from Lisp's conditions and restarts. Scheme's type system is extraordinarily lightweight. There's no way for the user to define new types, nor even a lightweight way to query for an object's type (unless I've missed something, one must use the various type predicates one-by-one). Relatedly, there's no way to declare variable or function types; no way to pass that information on to an optimising compiler. There are no compiler macros. Indeed, compilation in general is woefully underspecified. There's no object-orientation: no classes, no generic functions, none of that. One has to roll one's own if one wishes to. Although it does have cond-expand, unlike Lisp Scheme doesn't specify READ-SUPRESS which works in conjunction with #+ and #- to skip variant syntax supported by other implementations. This raises the issue of the reader in general. Scheme's reader is not extensible; it lacks reader macros. It provides no access to the current readtable, or any way to manipulate it. Scheme doesn't even have a general (i.e., unhygienic) macro facility! Its hygienic macros are sufficient for many use cases, but not all — e.g. anaphoric macros. Its iteration construct (yes, singular!) is severely limited. There's no general facility like LOOP. It lacks settable places (this is the capability in Lisp of writing `(setf (getf 'foo bar) 'baz)`). Scheme does finally have dynamic variables, although they are more unwieldy to use than Lisp's specials. I do like its well-specified numeric tower. > Modern Schemes like Chicken have fairly extensive collections of practical libraries and features that barebones Scheme implementations lack. But they require that for even very basic functionality (like hashtables!). One of Common Lisp's downfalls is having to use implementation-specific functionality; Scheme is worse. A related problem with Lisp is that Gray streams aren't part of the standard. But Scheme's ports are even less-specified than Lisp's streams. > To add to that, Scheme is far more elegant than CL, and doesn't contain all of the ancient crud of CL, so is far more pleasant and easy to program in. You know what I find pleasant? A language which anticipates my needs and my problems, and has already solved them. Time and time again I find that Common Lisp has done exactly that. I'll certainly admit that there are parts of Lisp I'd change (the default upcasing is hideous; some of the function names are ugly; the varying argument order between similar functions is beyond lame). But I'd never want to use a language which treats NIL as true! Scheme's not really a toy: it's clay which can be used by thinkers as well as students to play with problems. But it's not suitable for writing portable, high-performance, industrial-strength, real-world problems. Common Lisp is. [1] http://trac.sacrideo.us/wg/wiki/R7RSHomePage |