5 ms·

Here's a question the article doesn't answer: why Common Lisp? I.e. why not Scheme? Scheme is a plenty powerful language these days with all the libraries it

Here's a question the article doesn't answer: why Common Lisp? I.e. why not Scheme? Scheme is a plenty powerful language these days with all the libraries it has available. Granted, it doesn't have history going back to the 1950s, but it does date back to the 1970s. There are also multiple implementations, each with its own set of strengths. And there are some solid standards written for the language that have good implementations. It seems to have all the exact same features they're saying make CL a good choice (e.g. it's hard for me to imagine that a language older than most working programmers doesn't have "longevity" or "staying power.") Besides, if you click through to https://stevelosh.com/blog/2018/08/a-road-to-common-lisp/#s8-ugliness https://stevelosh.com/blog/2018/08/a-road-to-common-lisp/#s8... (linked in the article), it shows a picture of the index of CLtL, where the entry for 'kludges' spans the entire book lol!

xmcqdpt2 3y ago
I recently decided to try a scheme and did not find any that had supported Windows as a first class platform, so that's one limitation. By comparison SBCL just runs on Windows without any difficulties.
- jhgb 3y ago
  I believe that Chez should support Windows very well, even to the extent of supporting COM calls.
- kerkeslager 3y ago
  Racket has supported Windows since I tried it out in high school, which was a long, long time ago. The thing with Schemes is that you can implement one in an afternoon, and you can probably add some neato feature in the same afternoon, so there are a ton of Schemes out there. But you can't build community, ecosystem of libraries, platform support, etc. that you would want for a language you're going to use in production. Racket has been around for a long time, is used in various production systems, and has a solid community. It actually has the best standard library I know of for writing desktop GUIs, which might not be much of a claim to fame in 2023, but makes it super useful for writing small desktop tools. It definitely does some things better than others, like any language, but I think I'd be comfortable committing to it for a production project any day, which is more than I can say for any other Scheme.
  - lispm 3y ago
    Common Lisp has Allegro CL and LispWorks, both with GUI libs, interface builder and extensive support for Windows.
chlorion 3y ago
That's a very good question and the same thing I ask myself whenever I consider using some lisp (for hobby purposes mostly). I came to the conclusion that scheme is a better language from a technical standpoint and I enjoy using it more, but the primary issue is that lisp is already sort of niche, and scheme is like a niche inside of a niche, which in practice results in the "ecosystem" being very weak. By ecosystem, I mean how much activity there is on the implementations, but moreso the available libraries and the quality of the available libraries! An example of the ecosystem thing would be elisp. elisp has a ton of libraries available, there "s.el" for string manipulation, dash for lists, "f.el" for files and paths, "ht" for hashtables, and a lot more. Vanilla Emacs comes with around 5 million lines worth of Elisp OOTB too, this includes stuff like regex, a custom sexpr based regex DSL called "rx", json and xml parsers, sqlite bindings, etc. Very rarely do I feel like I'm missing something in elisp, with the exception of concurrency support! When I used scheme, I was not able to find alternatives to many of these things and felt pretty limited. Schemes do tend to have better "native" support for some things like list manipulation, so it's at least usable without something like dash. Anyways, Guile scheme seems like the most usable scheme to me right now and gets a bit of attention thanks to guix, but I think common lisp gets a bit more attention right now, and neither can compare to something like ruby or python sadly! So this could be one reason one might prefer common lisp over scheme I guess. So for me personally, common lisp feels too old and clunky to comfortably use, scheme is nice but lacks support in a lot of areas, so in practice I end up not using either of them. I have yet to try racket though and it looks like it addresses most of my issues.
- Paul-Craft 3y ago
  > Very rarely do I feel like I'm missing something in elisp, with the exception of concurrency support! I have some good news for you, then! Cooperative threading was added in Emacs 26: https://www.gnu.org/software/emacs/manual/html_node/elisp/Threads.html https://www.gnu.org/software/emacs/manual/html_node/elisp/Th... https://www.emacswiki.org/emacs/NoThreading https://www.emacswiki.org/emacs/NoThreading I've never used it, but the big disadvantage seems to be that unless you're going to do some super advanced macrology, any function you run within a thread needs to explicitly call `thread-yield` in order to yield back to the scheduler so other threads can run. I don't know of any library or anything that makes it so you can just take a function that isn't thread-aware, run it concurrently with other possibly not thread-aware functions, and have it all work sensibly, but at least the building blocks are there. --- If that doesn't suit you, Emacs 25 introduced generators! https://www.gnu.org/software/emacs/manual/html_node/elisp/Generators.html https://www.gnu.org/software/emacs/manual/html_node/elisp/Ge... Generators have some funky interactions with `unwind-protect`, so handle with care. --- Finally, there's also a (really old and probably won't work as is anymore, but also probably fun to poke at) coroutine library available: https://www.emacswiki.org/emacs/CoRoutines https://www.emacswiki.org/emacs/CoRoutines --- I'm sure one of those (probably emacs threads) will meet your needs nicely. :)
garbagecoder 3y ago
They don’t mention Clojure at all either. Since it runs on the JVM, if the JVM can do it, so can Clojure, even if inelegantly. I used it on one project where there was a wage involved, just one, but I do love it.
schemescape 3y ago
I'm not qualified to respond, but I switched from Scheme to Common Lisp for CL's condition system and REPL. Other than Smalltalk and some very niche languages, I couldn't find any languages that, after hitting an error, let me reliably interactively inject new/replacement code from my code editor and then re-run the function (obviously assuming it is reasonable to do so).
hajile 3y ago
I have some reasons. * Even the fastest of the schemes is slower than SBCL. * The interactive development features in Common Lisp are there because they got baked into the spec. They aren’t really a thing with scheme. * Common Lisp has a specification everyone follows. Scheme has THREE completely different specs everyone fights over. Version 6 is the LEAST common (though probably the best for real work), but it’s also the choice of Chez scheme which is the fastest implementation (last I checked). * Related are the SRFIs. There’s over 200 of them. The language isn’t useful unless a bunch of these have been baked into the compiler. This is HORRIBLE for users. If you want to do something, you must search the SRFIs, find the correct one, look up if it’s actually supported, then read the spec because implementations don’t actually documents this stuff in their own docs. https://srfi.schemers.org/ https://srfi.schemers.org/ This all makes portability a disaster. Imagine trying to make a library that works across three versions of the language (all with different features and ways of doing basic things like importing code). Next, you have to work around which implementations support which basic SRFI (eg, Can I use list operators beyond car/cdr? Can I use basic string operators? Mutable arrays? Hash Tables? Records? Threads? Integer bitwise operators? Streams? The other 200+ SRFIs that cover basic stuff that should have been in the language itself? The result is everyone constantly recreating the wheel in slightly different ways. R7RS-large was supposed to fix some of the worst of these issues, but we’re 10 years out now and still waiting.
lispm 3y ago
I like Scheme, but prefer Common Lisp for its environments and the old-school feel of the language. > And there are some solid standards Good things don't come alone: R5RS, R6RS, R7RS, RNRS + SRFI X..Y, IEEE Scheme, Racket, ... > entry for 'kludges' That's a form of self-deprecating humor, if you missed it. There are many more funny index entries in CLtL. The core designers did not take themselves too serious. Especially Guy L Steele. For example Dave Moon said about the search for a name for the language: "...whatever we call this common Lisp" and this time, among great sadness and consternation that a better name could not be had, it was selected."
- Paul-Craft 3y ago
  > That's a form of self-deprecating humor, if you missed it. No, of course, I didn't miss that. ;) Yes, it was funny! But the mere fact that it's a joke made by none other than Guy Steele, and that Lisp as a language goes back to 1960, which is old enough to make it eligible for a retirement pension in most countries, tells me that there's a bit of truth to it.
  - lispm 3y ago
    Scheme is from 1975 with huge influences from Lisp -> 48 years. Sussman is 76, Steele is 68. I don't think it's a only a problem of Common Lisp, which, btw., is younger than Scheme (which wasn't created completely new in a vacuum). The Scheme Report revisions upto R5RS for example ignored a lot of practical problems (no error handling, no namespaces, no object system, ...). The kludges then were outside of the language definition. But having no error handling in the language definition is not better than having one with less than ideal integration into the language. It's just a different way to deal with the problem of features which need a deep language integration: writing a larger standard with compromises or just pretend that one defines a language primarily for teaching computer science concepts (and which lacks really necessary features like error handling). The language definition then should only have as many (very dense) pages, as a student could handle in introductory course. R6RS was an attempt to get a more complete language, which then kind of failed and was controversial amongst users and implementors. I'd think, a to defined a language with kludges, but which tries to address practical problems, is a respectable and useful approach. Being self-aware that not everything is ideal is also nothing to look down to.

xmcqdpt2 3y ago

I recently decided to try a scheme and did not find any that had supported Windows as a first class platform, so that's one limitation. By comparison SBCL just runs on Windows without any difficulties.

jhgb 3y ago
I believe that Chez should support Windows very well, even to the extent of supporting COM calls.
kerkeslager 3y ago
Racket has supported Windows since I tried it out in high school, which was a long, long time ago. The thing with Schemes is that you can implement one in an afternoon, and you can probably add some neato feature in the same afternoon, so there are a ton of Schemes out there. But you can't build community, ecosystem of libraries, platform support, etc. that you would want for a language you're going to use in production. Racket has been around for a long time, is used in various production systems, and has a solid community. It actually has the best standard library I know of for writing desktop GUIs, which might not be much of a claim to fame in 2023, but makes it super useful for writing small desktop tools. It definitely does some things better than others, like any language, but I think I'd be comfortable committing to it for a production project any day, which is more than I can say for any other Scheme.
- lispm 3y ago
  Common Lisp has Allegro CL and LispWorks, both with GUI libs, interface builder and extensive support for Windows.

chlorion 3y ago

That's a very good question and the same thing I ask myself whenever I consider using some lisp (for hobby purposes mostly). I came to the conclusion that scheme is a better language from a technical standpoint and I enjoy using it more, but the primary issue is that lisp is already sort of niche, and scheme is like a niche inside of a niche, which in practice results in the "ecosystem" being very weak. By ecosystem, I mean how much activity there is on the implementations, but moreso the available libraries and the quality of the available libraries! An example of the ecosystem thing would be elisp. elisp has a ton of libraries available, there "s.el" for string manipulation, dash for lists, "f.el" for files and paths, "ht" for hashtables, and a lot more. Vanilla Emacs comes with around 5 million lines worth of Elisp OOTB too, this includes stuff like regex, a custom sexpr based regex DSL called "rx", json and xml parsers, sqlite bindings, etc. Very rarely do I feel like I'm missing something in elisp, with the exception of concurrency support! When I used scheme, I was not able to find alternatives to many of these things and felt pretty limited. Schemes do tend to have better "native" support for some things like list manipulation, so it's at least usable without something like dash. Anyways, Guile scheme seems like the most usable scheme to me right now and gets a bit of attention thanks to guix, but I think common lisp gets a bit more attention right now, and neither can compare to something like ruby or python sadly! So this could be one reason one might prefer common lisp over scheme I guess. So for me personally, common lisp feels too old and clunky to comfortably use, scheme is nice but lacks support in a lot of areas, so in practice I end up not using either of them. I have yet to try racket though and it looks like it addresses most of my issues.

Paul-Craft 3y ago
> Very rarely do I feel like I'm missing something in elisp, with the exception of concurrency support! I have some good news for you, then! Cooperative threading was added in Emacs 26: https://www.gnu.org/software/emacs/manual/html_node/elisp/Threads.html https://www.gnu.org/software/emacs/manual/html_node/elisp/Th... https://www.emacswiki.org/emacs/NoThreading https://www.emacswiki.org/emacs/NoThreading I've never used it, but the big disadvantage seems to be that unless you're going to do some super advanced macrology, any function you run within a thread needs to explicitly call `thread-yield` in order to yield back to the scheduler so other threads can run. I don't know of any library or anything that makes it so you can just take a function that isn't thread-aware, run it concurrently with other possibly not thread-aware functions, and have it all work sensibly, but at least the building blocks are there. --- If that doesn't suit you, Emacs 25 introduced generators! https://www.gnu.org/software/emacs/manual/html_node/elisp/Generators.html https://www.gnu.org/software/emacs/manual/html_node/elisp/Ge... Generators have some funky interactions with `unwind-protect`, so handle with care. --- Finally, there's also a (really old and probably won't work as is anymore, but also probably fun to poke at) coroutine library available: https://www.emacswiki.org/emacs/CoRoutines https://www.emacswiki.org/emacs/CoRoutines --- I'm sure one of those (probably emacs threads) will meet your needs nicely. :)

garbagecoder 3y ago

They don’t mention Clojure at all either. Since it runs on the JVM, if the JVM can do it, so can Clojure, even if inelegantly. I used it on one project where there was a wage involved, just one, but I do love it.

schemescape 3y ago

I'm not qualified to respond, but I switched from Scheme to Common Lisp for CL's condition system and REPL. Other than Smalltalk and some very niche languages, I couldn't find any languages that, after hitting an error, let me reliably interactively inject new/replacement code from my code editor and then re-run the function (obviously assuming it is reasonable to do so).

hajile 3y ago

I have some reasons. * Even the fastest of the schemes is slower than SBCL. * The interactive development features in Common Lisp are there because they got baked into the spec. They aren’t really a thing with scheme. * Common Lisp has a specification everyone follows. Scheme has THREE completely different specs everyone fights over. Version 6 is the LEAST common (though probably the best for real work), but it’s also the choice of Chez scheme which is the fastest implementation (last I checked). * Related are the SRFIs. There’s over 200 of them. The language isn’t useful unless a bunch of these have been baked into the compiler. This is HORRIBLE for users. If you want to do something, you must search the SRFIs, find the correct one, look up if it’s actually supported, then read the spec because implementations don’t actually documents this stuff in their own docs. https://srfi.schemers.org/ https://srfi.schemers.org/ This all makes portability a disaster. Imagine trying to make a library that works across three versions of the language (all with different features and ways of doing basic things like importing code). Next, you have to work around which implementations support which basic SRFI (eg, Can I use list operators beyond car/cdr? Can I use basic string operators? Mutable arrays? Hash Tables? Records? Threads? Integer bitwise operators? Streams? The other 200+ SRFIs that cover basic stuff that should have been in the language itself? The result is everyone constantly recreating the wheel in slightly different ways. R7RS-large was supposed to fix some of the worst of these issues, but we’re 10 years out now and still waiting.

lispm 3y ago

I like Scheme, but prefer Common Lisp for its environments and the old-school feel of the language. > And there are some solid standards Good things don't come alone: R5RS, R6RS, R7RS, RNRS + SRFI X..Y, IEEE Scheme, Racket, ... > entry for 'kludges' That's a form of self-deprecating humor, if you missed it. There are many more funny index entries in CLtL. The core designers did not take themselves too serious. Especially Guy L Steele. For example Dave Moon said about the search for a name for the language: "...whatever we call this common Lisp" and this time, among great sadness and consternation that a better name could not be had, it was selected."

Paul-Craft 3y ago
> That's a form of self-deprecating humor, if you missed it. No, of course, I didn't miss that. ;) Yes, it was funny! But the mere fact that it's a joke made by none other than Guy Steele, and that Lisp as a language goes back to 1960, which is old enough to make it eligible for a retirement pension in most countries, tells me that there's a bit of truth to it.
- lispm 3y ago
  Scheme is from 1975 with huge influences from Lisp -> 48 years. Sussman is 76, Steele is 68. I don't think it's a only a problem of Common Lisp, which, btw., is younger than Scheme (which wasn't created completely new in a vacuum). The Scheme Report revisions upto R5RS for example ignored a lot of practical problems (no error handling, no namespaces, no object system, ...). The kludges then were outside of the language definition. But having no error handling in the language definition is not better than having one with less than ideal integration into the language. It's just a different way to deal with the problem of features which need a deep language integration: writing a larger standard with compromises or just pretend that one defines a language primarily for teaching computer science concepts (and which lacks really necessary features like error handling). The language definition then should only have as many (very dense) pages, as a student could handle in introductory course. R6RS was an attempt to get a more complete language, which then kind of failed and was controversial amongst users and implementors. I'd think, a to defined a language with kludges, but which tries to address practical problems, is a respectable and useful approach. Being self-aware that not everything is ideal is also nothing to look down to.