103

Note: I am not asking which to learn, which is better, or anything like that.

I picked up the free version of SICP because I felt it would be nice to read (I've heard good stuff about it, and I'm interested in that sort of side of programming).

I know Scheme is a dialect of Lisp and I wondered: what is the actual difference is between Scheme and, say, Common Lisp?

There seems to be a lot about 'CL has a larger stdlib...Scheme is not good for real-world programming..' but no actual thing saying 'this is because CL is this/has this'.

John Clements
  • 16,895
  • 3
  • 37
  • 52
PrettyPrincessKitty FS
  • 6,117
  • 5
  • 36
  • 51
  • 7
    "Scheme is not good for real-world programming" ... I do real world programming in Scheme (ok, not much). – knivil Mar 20 '11 at 14:26
  • Not sure if this is the subtext but I would recommend just doing the SICP exercises in Scheme. You can use nearly any implementation with the right parameters because the subset they focus on is so small. You'd just need to find the right parameters for your choice, for instance, in Racket it would probably be R5RS-mode. A lot of ideas from SICP will help you in your further Lisp study, even if you go on to use Common Lisp or even Clojure instead. – okonomichiyaki Mar 20 '11 at 14:42
  • 14
    Last I saw, the Scheme spec was about 50 pages, and the CL spec was over 1000. So just open up the CL spec to any page, and chances are good that's something that's in CL but not Scheme. :-) – Ken Mar 20 '11 at 15:06
  • @knivil I was quoting from other SO questions I've seen about which to use. – PrettyPrincessKitty FS Mar 20 '11 at 15:14
  • 1
    possible duplicate of [Common Lisp or Scheme?](http://stackoverflow.com/questions/108201/common-lisp-or-scheme) – nawfal Jul 21 '14 at 07:44

4 Answers4

126

This is a bit of a tricky question, since the differences are both technical and (more importantly, in my opinion) cultural. An answer can only ever provide an imprecise, subjective view. This is what I'm going to provide here. For some raw technical details, see the Scheme Wiki.

Scheme is a language built on the principle of providing an elegant, consistent, well thought-through base language substrate which both practical and academic application languages can be built upon.

Rarely will you find someone writing an application in pure R5RS (or R6RS) Scheme, and because of the minimalistic standard, most code is not portable across Scheme implementations. This means that you will have to choose your Scheme implementation carefully, should you want to write some kind of end-user application, because the choice will largely determine what libraries are available to you. On the other hand, the relative freedom in designing the actual application language means that Scheme implementations often provide features unheard of elsewhere; PLT Racket, for example, enables you to make use of static typing and provides a very language-aware IDE.

Interoperability beyond the base language is provided through the community-driven SRFI process, but availability of any given SRFI varies by implementation.

Most Scheme dialects and libraries focus on functional programming idioms like recursion instead of iteration. There are various object systems you can load as libraries when you want to do OOP, but integration with existing code heavily depends on the Scheme dialect and its surrounding culture (Chicken Scheme seems to be more object-oriented than Racket, for instance).

Interactive programming is another point that Scheme subcommunities differ in. MIT Scheme is known for strong interactivitiy support, while PLT Racket feels much more static. In any case, interactive programming does not seem to be a central concern to most Scheme subcommunities, and I have yet to see a programming environment similarly interactive as most Common Lisps'.

Common Lisp is a battle-worn language designed for practical programming. It is full of ugly warts and compatibility hacks -- quite the opposite of Scheme's elegant minimalism. But it is also much more featureful when taken for itself.

Common Lisp has bred a relatively large ecosystem of portable libraries. You can usually switch implementations at any time, even after application deployment, without too much trouble. Overall, Common Lisp is much more uniform than Scheme, and more radical language experiments, if done at all, are usually embedded as a portable library rather than defining a whole new language dialect. Because of this, language extensions tend to be more conservative, but also more combinable (and often optional).

Universally useful language extensions like foreign-function interfaces are not developed through formal means but rely on quasi-standard libraries available on all major Common Lisp implementations.

The language idioms are a wild mixture of functional, imperative, and object-oriented approaches, and in general, Common Lisp feels more like an imperative language than a functional one. It is also extremely dynamic, arguably more so than any of the popular dynamic scripting languages (class redefinition applies to existing instances, for example, and the condition handling system has interactivity built right in), and interactive, exploratory programming is an important part of "the Common Lisp way." This is also reflected in the programming environments available for Common Lisp, practically all of which offer some sort of direct interaction with the running Lisp compiler.

Common Lisp features a built-in object system (CLOS), a condition handling system significantly more powerful than mere exception handling, run-time patchability, and various kinds of built-in data structures and utilites (including the notorious LOOP macro, an iteration sublanguage much too ugly for Scheme but much too useful not to mention, as well as a printf-like formatting mechanism with GOTO support in format strings).

Both because of the image-based, interactive development, and because of the larger language, Lisp implementations are usually less portable across operating systems than Scheme implementations are. Getting a Common Lisp to run on an embedded device is not for the faint of heart, for example. Similarly to the Java Virtual Machine, you also tend to encounter problems on machines where virtual memory is restricted (like OpenVZ-based virtual servers). Scheme implementations, on the other hand, tend to be more compact and portable. The increasing quality of the ECL implementation has mitigated this point somewhat, though its essence is still true.

If you care for commercial support, there are a couple of companies that provide their own Common Lisp implementations including graphical GUI builders, specialized database systems, et cetera.

Summing up, Scheme is a more elegantly designed language. It is primarily a functional language with some dynamic features. Its implementations represent various incompatible dialects with distinctive features. Common Lisp is a fully-fledged, highly dynamic, multi-paradigm language with various ugly but pragmatic features, whose implementations are largely compatible with one another. Scheme dialects tend to be more static and less interactive than Common Lisp; Common Lisp implementations tend to be heavier and trickier to install.

Whichever language you choose, I wish you a lot of fun! :)

Matthias Benkard
  • 15,497
  • 4
  • 39
  • 47
28

Some basic practical differences:

  • Common Lisp has separate scopes for variables and functions; whereas in Scheme there is just one scope -- functions are values and defining a function with a certain name is just defining a variable set to the lambda. As a result, in Scheme you can use a function name as a variable and store or pass it to other functions, and then perform a call with that variable as if it were a function. But in Common Lisp, you need to explicitly convert a function into a value using (function ...), and explicitly call a function stored in a value using (funcall ...)
  • In Common Lisp, nil (the empty list) is considered false (e.g. in if), and is the only false value. In Scheme, the empty list is considered true, and (the distinct) #f is the only false value
newacct
  • 119,665
  • 29
  • 163
  • 224
  • 3
    For me the first point @newacct makes is the most important, by far. If functions are not first-class objects, a lot of the really fun, "creative" programming feel is lost for me. OK, there may be "practical" considerations, for speed, etc, but if I want functional, immutable programming, there's just no comparison, IMHO. And if I want practicality, I can go to Clojure and get the best of both worlds. Common Lisp has its place, but I suspect that's in the world of "industry", where I am sure people are very grateful for it. – Alex Gian Sep 04 '18 at 09:31
  • 4
    CL still has first class functions. That it has a separate namespace for functions doesn't mean it doesn't have first class functions (yes, there's a little more syntax required, but _that's all_). – mwal Apr 26 '19 at 15:27
  • 1
    re: functional in CL, bigger obstacle is lack of mandatory TCO. Sure, some implementations support it, but then it means you're not writting portable CL code anymore, and portability seems one of main drawing points – Coderino Javarino Sep 04 '20 at 11:41
11

That's a hard question to answer impartially, especially because many of the LISP folks would classify Scheme as a LISP.

Josh Bloch (and this analogy may not be his invention) describes choosing a language as being akin to choosing a local pub. In that light, then:

The "Scheme" pub has a lot of programming-languages researchers in it. These people spend a lot of attention on the meaning of the language, on keeping it well-defined and simple, and on discussing innovative new features. Everyone's got their own version of the language, designed to allow them to explore their own particular corner of programming languages. The Scheme people really like the parenthesized syntax that they took from LISP; it's flexible and lightweight and uniform and removes many barriers to language extension.

The "LISP" pub? Well... I shouldn't comment; I haven't spent enough time there :).

John Clements
  • 16,895
  • 3
  • 37
  • 52
  • 2
    I am a regular in the CL pub and visited the Scheme pub for the first time today. Smaller variety of beers, no burgers, but elegant plates, which are much larger than in the CL pub, because they need to hold many more, smaller items. Beer is also served on plates. In the CL pub they use mugs. – BitTickler Dec 01 '21 at 20:07
  • 1
    Relevant: do you know how many 12-ounce beers will fit in a standard Wham-O frisbee? *Five*. Who needs mugs? ... More seriously, I think you're trying to make a point about one-size-fits-all-ness, but I just don't get it, probably because I spend too much time in the Scheme pub (or, more specifically, the Racket part of the Scheme pub, which insists that it's the only important part of the Scheme pub). – John Clements Dec 03 '21 at 01:43
  • So where is the scheme pub? Anything on Telegram? – flywire Jan 19 '23 at 08:29
2

scheme:

  • orginally very few specifications (new R7RS seems to be heavier)
  • due to the easy syntax, scheme can be learned quickly
  • implementations provide additional functions, but names can differ in different implementations

common lisp:

  • many functions are defined by the bigger specification
  • different namespace for functions and variables (lisp-2)

that are some points, sure there are many more, which i don't remember right now.

Moe
  • 1,021
  • 1
  • 9
  • 16