I'm wondering what is people's opinion on modern Scheme dialects like Racket vs. Common Lisp? It seems to be pretty stable, with active development community, and comes with batteries installed.
Well, first off Racket is a different language from Scheme, although it's very similar. It's definitely very cool, and the folks involved have invested a tremendous amount of effort into it.
At the end of the day, though, I prefer Lisp. I like that it's standarised; I like that so much code runs in just about every implementation; I like that — as someone noted elsethread — in Lisp it's not uncommon for libraries to be done.
I like that Lisp is much more complete than Scheme. Standarised places are great. Standardised extensible types are wonderful. I don't like that so many in the Scheme community are so very opposed to adding to the language, no matter how painful the lack (witness the abject failure of R6RS).
CLOS is amazingly good, better than any object system in any other language I've used. Scheme doesn't have a standard version.
I think that multiple namespaces is a huge feature. A lot of Schemers disagree, but I don't see a good reason for functions, macros, classes, tags &c. to share a namespace, and it makes programs more obtuse.
I don't care for Scheme's separate Boolean types, nor for the way it splits NIL, () & #f. They make code less concise, for no terribly good reason IMHO. Maybe that's a matter of taste, but I think it reflects the pragmatism of Lisp vice the idealism of Scheme.
Lisp has standardised compiler macros. Lisp's normal macros are, I believe, more powerful than Scheme's (as I understand it, one can implement Scheme macros in Lisp but not Lisp macros in Scheme).
Scheme's dynamic-wind is broken, while UNWIND-PROTECT isn't.
Scheme's continuations in general are really awesome, but make it slightly too difficult to optimise code. I think it's great to have them available in an educational language, but not so great to have them in a general-purpose industrial language meant for real programs.
Generally, when I come across some corner of the Lisp standard I don't understand, some years later I'll recognise how incredibly valuable it is to be able to have it, and how great it is that every implementation has it. I never come across any corner of the Scheme standards, because they have no corners. Whenever I write Scheme I'm not really writing Scheme — I'm really writing guile or whatever.
Scheme's a wonderful language for teaching C.S. concepts like continuations & computer science in general — it's not IMHO a good language for industrial-strength software.
Racket is a single implementation of what used to be a Scheme but has now grown to be something else entirely different. It's really cool — I just wish everyone involved had spent that time on SBCL & portable Common Lisp libraries instead. It's a free world, of course!
You forgot arguably the most important bit: Racket is not an image-based interactive language (every time you evaluate code in DrRacket the entire state is wiped) and its designers do not think that's worth doing right. Of course there are some hacky solutions (geiser) that are full of gotchas and, compared to Common Lisp, can only be seen as entirely broken.
I think the most important plus for CL is that CL is image-based, and that every important thing is already standardized, either on the ANSI standard, or de-facto via mature libraries.
CL is not image based. That's a popular implementation detail.
There are several implementations which are not image based. If we look closely we would find probably ten CL implementations which are not image-based of which maybe five are still somewhat in use. The Common Lisp standard also says absolutely nothing about programs/applications/images/libraries...
A prominent example for a CL implementation which is not image-based is ECL, Embeddable Common-Lisp:
---
Traditionally, Common Lisp implemenations have provided a function to save the dump all data from a running Lisp process into a file. The result was called the Lisp image and could be shipped to other version compatible implementations.Nowadays, having less control of the systems it runs in, a Lisp implementation must work very hard to dump memory images and be able to load and execute them afterwards.
ECL has chosen to avoid this process entirely. Instead, we conceive five different portable models for building and shippin your programs. The models, described in Table 1.1, enumerate the different kinds of files that ECL can portably produce. To get one or more of the products mentioned in the table, you may resort to a low level API described in Part III. However, we recommend a simpler way based on using System Definition Files to describe the structure of your project and let ECL build the desired target for you. This approach is described in the following sections.
---
