Hacker News new | ask | show | jobs
by munificent 1039 days ago
The Scheme community has long held tension between people who want to use Scheme as a teaching language, versus those who want to use it for writing real-world programs.

The former want the language to stay as minimal as possible with a tiny standard library so that there are fewer concepts and options for students to stumble over. The latter want a full-featured language (but still minimal, it is Scheme after all) with a large standard library of useful types and functions so they can get stuff done.

These two perspectives are both reasonable but fairly incompatible.

For most of its history, Scheme leaned towards education. Around the type of the sixth edition (RSR6), pulled somewhat the other way and the language and library spec got much bigger. This alienated a lot of folks who wanted to stay a small teaching language.

For RSR7, they tried to resolve that by simply splitting the language in two: a small one and a large one. Then each subcommunity can have what they want.

Around the same time, the language PLTScheme renamed itself to Racket to clarify that they aren't trying to be beholden to the overall direction of the Scheme community. Racket is also a "large Scheme" in that it's a Scheme-derived language that tries really hard to be batteries included for all sorts of uses. It also can be "subset" into smaller languages for use in teaching.

My impression (from far on the outside) is that Racket has taken up a lot of the oxygen, which may partially explain why RSR7-large never managed to reach consensus and ship.

4 comments

> My impression (from far on the outside) is that Racket has taken up a lot of the oxygen

For real world applications rather than education Racket and Clojure as well, in fact Clojure has taken up a lot of the oxygen across a variety of niche FP language eco systems. The Clojure toolchain and library support (much of it through the JVM and Java ecosystem) is excellent and far ahead of Racket for most of the same applications. But Racket starts faster and has a much smaller memory footprint. Depending on your workload and compatibility demands either the one or the other will be a clear favorite with Clojure coming out ahead.

But all of these and scheme (which I think is mostly propped up by virtue of being used a lot in education, I've yet to come across scheme in the wild) are very much niche languages. Clojure really does have an advantage of standing on the shoulders of Java and the JVM, without that I don't think it would have gotten as large as it did.

…but, we were talking about scheme, not clojure right?

> Clojure really does have an advantage of…

Look, I’m a fan of clojure, I spent two happy years using it. …but it seems obnoxious to bring it up here like this.

Is there really any reason to think that clojure has taken the wind out of the sails of the group of people who were using scheme?

It seems like a massive, totally unsubstantiated take, that really doesn’t add anything here.

The aggression in your response is entirely disproportionate to the comment you're replying to. I don't know who peed in your Cheerios, but it wasn't jacquesm.

We're talking about a minimal dynamically-typed Lisp language and speculating about its challenges around adoption and consensus. Given that Lisps are already a niche language, it's completely germane to bring up another minimal dynamically-typed Lisp that has almost certainly captured some of the overall small potential userbase.

Well, that may be your impression. But I know of two cases where scheme was being considered for commercial work and in both of those the decision was made to go for Clojure instead. It was relative to Racket as a replacement for more real world applications of Scheme that I mentioned this.
Indeed, thanks for the explanation. Not being super familiar with the Scheme community, “R7RS” sounds like a high-performance Audi.
It's the Revised Revised Revised Revised Revised Revised Revised Report on the Algorithmic Language Scheme, or (Revised)^7 Report on the Algorithmic Language Scheme, or R7RS.
(Because, of course, Scheme folks couldn't resist the urge to use a little recursion in the name of the spec instead of defining it as an iterated series of version numbers.)
But its both. Even if you don’t get the joke, you can pretty easily tell that R4RS, R5RS, RNRS represent an ordered list.
That is extremely well written thank you.
Thanks for the summary. Unless I am missing something, this seems like a pointless argument that the scheme community has. Why not just create a library separate from the standard and call it a day?
Because of homoiconicity and macros, the line between "language" and "library" is deliberately extremely blurry, if such a line exists at all.

Take a look at the list of proposed features and try to decide if you can clearly bucket them as language or library: https://srfi.schemers.org/

Thanks for giving some context on the matter. If the base language is not capable to provide a way to implement those, then that makes sense. I do like the idea of having the base being small but still capable to allow for these features to be implemented in a library. From the link you gave, it does seem that these would require more support than what is available in a smaller language.