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.
> 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.
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.
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.)
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?
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.
I don't have much more context than you, but one bit I did catch is that this resignation is for "R7RS-large" and not "R7RS-small" (which might even be complete already).
Traditionally, Scheme is as minimalist as possible by design. Therefore, the very idea of "R7RS-large" is likely controversial to some parties involved.
Apparently it has been an on-going argument for years on just what to include in R7RS-large, as we can see a Reddit thread from 2 years ago asking when it will be ready[0] and John Cowan (the person who is resigning from the committee) saying parts one and two are done and part three should "follow quiuckly thereafter".
> That depends entirely on how much time people can devote to it. The first two parts, Red and Tangerine, are already in place; Orange needs a few things pulled together before it can be voted on, and Amber should follow quickly thereafter.
I'm guessing getting that last 90+% of agreement stretched ever further and further on and as John said in the resignation letter, it was surely exhausting.
Spot on, that's why scheme is and probably always will be very much a niche language. They're not even trying. I wished we could collapse the Cambrian explosion of computer programming languages back into a small subset of what it is today to get fewer but healthier eco-systems. The amount of fragmentation is absolutely insane, and leads to a ton of duplicated effort and wasted resources. There are 100's of computer programming languages in active use and beyond say the top 100 or so there isn't much that isn't already covered multiple times.
But with the widespread connectivity that we have it is very easy to launch a new language and to gain some small level of adoption. Programming languages are like kids: you can launch them in a night but it takes a lifetime of dedication and support to make them successful and given how hard it is to distinguish a small effort going nowhere from a future winner all this does is saddle up outsiders with the cost of maintenance or ultimately a rewrite in some other, hopefully wider supported language.
It would be great if people would just label their languages clearly as 'experimental, not meant for production' and 'long term supported' up front. Some languages, notably, 'Haskell' are successful in spite of actively holding back large scale adoption. This is a much healthier approach. It shows that the language really has merit.
If you really want to undo the Cambrian explosion, you will get Fortran and Lisp. A better SQL, Prolog, and something like Haskell might also be useful/necessary.
I think programming language standards committees are not an unlikely venue for hot conflict, quite the opposite if you talk just about conflict without the word "hot". I don't have the background on this one though.
Do you have any experience reaching to similar organizations? for example reporting compiler or linker bugs or trying to get support for new features or platform that are not well documented? If you don't and think it sounds fun go ahead and have fun if you can do that work without getting dragged into hot conflict.
Lisp is 65 years old and its future will be longer than its past! Another way to look at a fast-moving industry is that it's all hype and flutter with the occasional solid achievement.
Yeah, I think there's an ambiguous connotation sometimes, such as in "academic politics is so fierce, becuase the stakes are so small" that it might just be people being petty about, say, small-pond status, because they have nothing else.
In this case, however, it might be more that there's an innate value that a small number of people recognize as important, so they care about it in a way that seems outsized, to people who aren't aware of that importance.
It's the Revised Revised Revised Revised Revised Revised Revised Report on the algorithmic programming language Scheme. That's 7 "Revised"s, hence R7RS. Basically the RxRSes are full specifications of what you need in a Scheme implementation to conform to the Xth iteration of the language.
So weird seeing CL code without a bunch of (declare (type (integer 0) n))'s everywhere. That's the only thing which keeps me with CL instead of Scheme (I'm rather fond of syntax-rules, case-lambda, case sensitivity, and being able to do things like...
(define range+ (make-range-merger +))
(define (double-range range)
(range+ range range))
Revised report version 7. The current scheme standardization. It proceeded R6RS which many felt was too large, and added too many things to the scheme standard (it’s only 90 pages long). R7RS was the compromise
Exactly. R7RS-small was meant to be a minimal core language, in the spirit of RnRS for n <= 5, whereas R7RS-large was meant to be a fairly complete set of standard libraries.
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.