4 ms·
The slew of differences dont seem very "designed", meaning some corner of the world won't end if life wasn't that way. They seem more like a consequence of "my
by sriku 10y ago
The slew of differences dont seem very "designed", meaning some corner of the world won't end if life wasn't that way. They seem more like a consequence of "my pet lisp interpreter as I began implementing it". I know that smell 'cos I've been through it myself and subsequently redesigned and reimplemented things.
- zeveb 10y agoExactly. After playing with different Lisp dialects for well over a decade I've come to the conclusion that Common Lisp's decisions are, generally, reasonably well-thought-out and not often terrible. I've not found a Lisp better-suited for the name. I'd love to see a new version of Common Lisp fixing some of the decisions which were terrible, but I don't see that happening.
- JohnStrange 10y agoWhy not, by the way? I've always wondered why the CL community hasn't come up with a new, improved standard for such a long time. Other old languages like Fortran and Ada are continuously updated. Why not CommonLisp?
- whyever 10y agoAs a lisp noob, I found many of common lisp's function names to be extremely arcane.
- qwertyuiop924 10y agoEh. I lean more on the scheme side of things, myself. One namespace, less historical cruft, and macros that are hygenic by default. It's a pretty good deal.
- zeveb 10y agoI actually think that the single namespace and weak macros are design mistakes. The lack of (as much) historical cruft is probably a Good Thing. call/cc is a great teaching tool but a terrible thing for use in an implementation supporting production software: it's goto without the limited scope of TAGBODY. I don't blame Scheme for not learning from Common Lisp, since the former predated the latter; indeed, Common Lisp learned from Scheme.
- qwertyuiop924 10y agoThe single namespace is quite useful, and if you think the macros are weak then you've only been looking at R5RS and not at real implementations: implicit rename, explicit rename, syntactic closures, and syntax-case are all as powerful as CL macros, and a good deal safer (although implicit rename is kind of expensive, and explicit rename requires explicit safety, so syntactic closures or syntax-case are the ways to go) Call/cc can indeed be useful in real software, although it's uncommon. However, teaching is part of Scheme's domain, so it's still a good thing either way. If you have an especially fast implementation of call/cc (like Chicken), you can use it to implement delimited continuations, which are safer, and can express common uses of call/cc far more elegantly. Racket (it should be noted that Racket isn't a scheme, but it's close enough that it's kind of "in the family" as it were) and Guile (which IS a scheme) have these as part of the core language.
- lispm 10y agoScheme was earlier developed than Common Lisp. But that's not the whole picture. The mainline of Lisp, which Common Lisp and the early Scheme (partly) is based on, existed earlier: Lisp 1.5 and then Maclisp. Scheme was then developed over several decades. It took 13 years to get Common Lisp from an idea to the ANSI Common Lisp standard. Sometimes the same people were involved. 1973 Maclisp 1974 Lisp Machine Lisp 1975 Scheme 1981 CL development started 1984 Common Lisp the Language published 1985 Scheme R2RS 1986 Scheme R3RS 1989 Common Lisp the Language II published (with CLOS, error handling, ...) 1990 IEEE Standard for Scheme published 1991 Scheme R4RS 1994 ANSI CL Standard published 1998 Scheme R5RS 2007 Scheme R6RS 2013 Scheme R7RS small