Am Sa., 1. Mai 2021 um 20:32 Uhr schrieb John Cowan <[email protected]>:
> > > On Sat, May 1, 2021 at 12:44 PM Amirouche Boubekki < > [email protected]> wrote: > > >> Regarding "initial education", except maybe scratch visual programming >> language, without picking a particular Scheme, R7RS is in a better >> position than any other programming language that I know. >> > > Remember that MIT ditched Scheme in favor of Python precisely because > professional programming today is mostly gluing things together. A friend > of mine once said that programming in Scheme is like building a ship in a > bottle: you have to do everything from scratch except making the tiny > little parts. > An important part of my work is teaching students. The comparison with the ship in a bottle is actually a very good reason why it can be much better to teach Scheme (than Python) even when your students will just use Python to glue things in their later professional careers. Good teaching does not mean teaching exactly the things you think your students will need but teaching them the fundamentals needed to enable them to constantly self-educate themselves about whatever will then be needed. > > R6RS is still very beautiful compared to most programming >> > languages, but many parts are far from the jewel that R5RS is. >> > > If R8RS gives up on portability, what will be the point of R8RS then? > > See Clinger's paper "R7RS Considered Unifier of Previous Standards". His > view (which I did not foresee but with which I agree) is that R6RS focused > on portability, R7RS-small on interoperability. > I have thought about it a bit more. I believe that it boils down to a triviality. It just says that the language standard of R7RS-small compared to R6RS is even smaller (which may be good or bad depending on where you look at it) than it seems at first glance. The set of portable R6RS programs is larger than the set of portable R7RS-small programs (ignoring the fact that all countable infinities are of the same cardinality), which trivially implies that there are fewer possible R6RS implementations than R7RS-small implementations (in the sense that R6RS implementations must be able to cope with more programs in a defined manner). Marc
