3 ms·

I've never done work with CL, but I've done quite a bit of Racket. What does CL offer that Racket doesn't? I've found Racket to be fairly complete, and the area

I've never done work with CL, but I've done quite a bit of Racket. What does CL offer that Racket doesn't? I've found Racket to be fairly complete, and the areas where it's not are usually quite simple to fill in (thus seem pretty clearly intentionally left open-ended).

peatmoss 8y ago
As a Racket dabbler, I’d say there are a couple things: - performant implementations (SBCL in particular is a standout). I mean, Racket’s pretty good, and will typically blow the doors off Python, but SBCL is in a different league. - multiple implementations conforming more or less to a standard. This can also be a distraction, but is on balance a nice thing to have, particularly if you wanted, for example, an implementation that ran on the JVM (ABCL). - different set of libraries. Racket’s library situation is pretty good, but sometimes CL will have something that Racket doesn’t (and sometimes the other way around)
- sigzero 8y ago
  Racket should be becoming more performant once the Chez integration is done.
  - dleslie 8y ago
    I wouldn't hold your breath; Racket isn't that much slower than Chez, and both are slower than sbcl. https://ecraven.github.io/r7rs-benchmarks/ https://ecraven.github.io/r7rs-benchmarks/ https://benchmarksgame-team.pages.debian.net/benchmarksgame/which-programs-are-fast.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
  - bad_login 8y ago
    According to Mathew Flatt it will fasten racket. https://www.youtube.com/watch?v=t09AJUK6IiM https://www.youtube.com/watch?v=t09AJUK6IiM
mikelevins 8y ago
A language designed for modifying programs while they run. Common Lisp and Smalltalk are languages designed to support modifying programs while they run. It's the standard way to develop a program in old-fashioned Lisp and Smalltalk systems: you start up your language runtime and then teach it, incrementally and interactively, to be the application you want. Interactive repls are pretty common nowadays, but a repl is not the same as being designed to support programming-as-teaching. Consider the Common Lisp generic function UPDATE-INSTANCE-FOR-REDEFINED-CLASS. It's in the language standard. It provides an extensible mechanism that the runtime uses to update existing instances of a class when the class is redefined. Why would you ever want such a function at all, much less want it to be part of the language standard? Because the authors of the Common Lisp language standard were experienced Lisp hackers. They took for granted that the way you write a program is you start your Lisp and then interactively teach it how to be the application. You don't want to have to stop the program and rebuild it just because you redefined a class. That's silly. The runtime should know how to update any existing instances to reflect the new definition, because telling the Lisp new definitions as it runs is the standard way that you normally work. Old-fashioned Lisp and Smalltalk systems are full of features that make this assumption--that you build an application by interactively teaching a running program how to be the application. As far as I know, they're the only development systems designed with that assumption (although, if Racket has such features and I overlooked them, I'd be glad to know it!). If you're not familiar with that style of programming (and I think most programmers are not), or if you don't prefer it, then something like UPDATE-INSTANCE-FOR-REDEFINED-CLASS makes no sense. On the other hand, if you prefer that way of working, as I do, then the absence of features like UPDATE-INSTANCE-FOR-REDEFINED-CLASS is as uncomfortable as a missing tooth.

peatmoss 8y ago

As a Racket dabbler, I’d say there are a couple things: - performant implementations (SBCL in particular is a standout). I mean, Racket’s pretty good, and will typically blow the doors off Python, but SBCL is in a different league. - multiple implementations conforming more or less to a standard. This can also be a distraction, but is on balance a nice thing to have, particularly if you wanted, for example, an implementation that ran on the JVM (ABCL). - different set of libraries. Racket’s library situation is pretty good, but sometimes CL will have something that Racket doesn’t (and sometimes the other way around)

sigzero 8y ago
Racket should be becoming more performant once the Chez integration is done.
- dleslie 8y ago
  I wouldn't hold your breath; Racket isn't that much slower than Chez, and both are slower than sbcl. https://ecraven.github.io/r7rs-benchmarks/ https://ecraven.github.io/r7rs-benchmarks/ https://benchmarksgame-team.pages.debian.net/benchmarksgame/which-programs-are-fast.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- bad_login 8y ago
  According to Mathew Flatt it will fasten racket. https://www.youtube.com/watch?v=t09AJUK6IiM https://www.youtube.com/watch?v=t09AJUK6IiM

mikelevins 8y ago

A language designed for modifying programs while they run. Common Lisp and Smalltalk are languages designed to support modifying programs while they run. It's the standard way to develop a program in old-fashioned Lisp and Smalltalk systems: you start up your language runtime and then teach it, incrementally and interactively, to be the application you want. Interactive repls are pretty common nowadays, but a repl is not the same as being designed to support programming-as-teaching. Consider the Common Lisp generic function UPDATE-INSTANCE-FOR-REDEFINED-CLASS. It's in the language standard. It provides an extensible mechanism that the runtime uses to update existing instances of a class when the class is redefined. Why would you ever want such a function at all, much less want it to be part of the language standard? Because the authors of the Common Lisp language standard were experienced Lisp hackers. They took for granted that the way you write a program is you start your Lisp and then interactively teach it how to be the application. You don't want to have to stop the program and rebuild it just because you redefined a class. That's silly. The runtime should know how to update any existing instances to reflect the new definition, because telling the Lisp new definitions as it runs is the standard way that you normally work. Old-fashioned Lisp and Smalltalk systems are full of features that make this assumption--that you build an application by interactively teaching a running program how to be the application. As far as I know, they're the only development systems designed with that assumption (although, if Racket has such features and I overlooked them, I'd be glad to know it!). If you're not familiar with that style of programming (and I think most programmers are not), or if you don't prefer it, then something like UPDATE-INSTANCE-FOR-REDEFINED-CLASS makes no sense. On the other hand, if you prefer that way of working, as I do, then the absence of features like UPDATE-INSTANCE-FOR-REDEFINED-CLASS is as uncomfortable as a missing tooth.