Re: Spec vs code, user-driven vs designer-driven Lassi Kortela 01 May 2021 15:04 UTC
> Consolidated response to a couple of points Thanks for joining in! > I think the python 2 / 3 problem was cultural. This was mostly a > problem because companies think software should be written once and > never touched like physical buildings. Software should stand the test > of time over a period of hundred years. Except both the knowledge and > required skills is not there yet. The question of backward > compatibility should not be compared with CPython 2 /3 case only. Did > you read about the async yield from vs. async / await or even just the > async / await thing that I call "split brain syndrome"? no. It was and > is a pain. PR does not explain the whole story. There are many > approaches to bridge the gap between incompatible versions of the same > language (polyfill libraries such as python six, or even re-writing > the code such as 2to3.py or js babel). If Scheme aims to be the > perfect programming language, it should not be a primary concern > whether it is backward compatible or not. I'm not familiar with Python past the 2-3 split. I think a standard doesn't need to weigh in on design decisions like that. If we standardize existing work, then individual implementations can try different approaches to things like threads, and if a consensus emerges among them, then that consensus can be written up in RnRS. This is much less grueling for RnRS writers, and much more realistic. > What would be the advantage of moving to R8RS? Putting the R6 vs R7 split behind us. >> the idea of R6RS and R7RS-large is to write practical applications as well. > > That is confusing. What is a practical application? That is mostly a > problem with R7RS WG1 and WG2 phrasing. What about educational > purpose? Steering software engineering toward a good direction? What > about different hardwares architecture or constraints? I think there > is a big difference (sadly) between being successful in the job market > (army of developers), or succesful commericaly (money making, which > scheme does), or educational material (ok) or even research material > (ok too). To summarize, except there is no visible army of developers > that practice Scheme on a daily basis, Scheme is successful. IMHO RnRS is no longer a good primary vehicle for driving educational values. After R5RS the language became so complex (out of necessity) that no one can get all the details perfect. There will be ugly parts for compatibility and other reasons, it's not really possible to avoid anymore. R6RS is still very beautiful compared to most programming languages, but many parts are far from the jewel that R5RS is. Scheme's beauty should be presented in educational materials that concentrate on the parts of the language that the author likes best, and present a consistent vision that way. > As far as portability goes, it is possible across R6RS and R7RS. Tho, > a test suite that is not normative, and easy to re-use will help a > lot. The details are inconvenient enough to cause problems with everyday work, and they are not on track to be fixed since RnRS has been and is caught up with pursuing its creators' vision. > Chez / Guile / Racket have R6RS support, that does not say whether > R6RS is successful. Guix, the primary, biggest and almost only floss > program built with Guile, does not rely on R6RS. There are other big > programs / sets of programs such as C FFI automagic library or even > MES bootstrap that are used by Guix / Guile. All those are built with > Guile specific stuff e.g. the module system is not compliant, and even > if the rest was portable, it will require much tedious work to make it > run on another Scheme. Regarding Racket it is a big ecosystem but not > impact on the job market. Chez is the same, except there is little or > no reach in the floss community (the mailing list is silent, no big > floss project uses Chez). I think overall Gambit with JazzScheme, > Gerbil, and with secret industry users is more successful than those > you cited. True. Some implementations have good traction on their own. But it makes sense to study why portable Scheme doesn't get some of it. It's clear we can't standardize things fast enough in RnRS to support all that work, and I think we should give up on the ambition to do that. We can standardize the same stuff slower, with less rigor and more give-and-take with Scheme implementors, until a solid spec emerges on its own years later. If we start out pursuing a solid spec for threads or FFI and won't rest before we are done, we'll be exhausted and unhappy. >> And adding new people to the community is hard if no-one can figure out > which of the warring RnRS, if any, is legitimate. > > Nobody cares (meme https://i.redd.it/b9ca0ux5wkq41.jpg). My > understanding there is three reasons to take part in SRFI / RnRS: > > - Improve / communicate / gather software engineering practices and > have a conversation with knowledgeable people > > - Grow your audience to attract users in to your implementation, > possibly aiming for Turing award or such > > - Have feedback on your own ideas RnRS is like the World Cup of design rigor. A team will be exhausted if every game they play all year round is a World Cup game. This is in fact what we are now seeing among RnRS contributors. > None is Scheme specific. And forking the language and target JS or > wasm has a much bigger chance of success (including much more industry > adoption). What remains is "Scheme spirit" which I keep repeating is > according to me: aiming for perfection, and that leaves too much to > interpretation to guide any standardization work. Even if RnRS has broad compatibility, you can still aim for perfection in your codebase, and if complex RnRS features are split into options, there can be individual Scheme implementations that aim for perfection. If you pick a particular vision of perfection and drive it in RnRS, the next RnRS group will disagree and pick a different vision. It seems self-evident that the process is leading nowhere and is hurting Scheme's user community. If things keep going as they now do, there's no reason to believe that a future R8RS group will pick a vision compatible with the R6RS group or the R7RS-large group. They'll invent a third vision.