@John Cowan; An Olin Shivers-style rant (the Jack'n'Zac one that opens the SCSH manual) would be extremely tempting given your lack of ability to comprehend the immense harm that your position brought to the unique value proposition of Scheme. I've noticed there is little hope arguing with people like you.
Everytime you introduce a new standard, especially one that is backwards-incompatible, you split the codebase. Some people will write R6RS code that is incompatible with R5RS and R7RS implementations. Some people will write R7RS-large code that is incompatible with R6RS (and R7RS-small). Now we have R6RS which is even FORWARD-incompatible, and the 2 R7RS's which are SIDEWAYS incompatible, and you can't see a problem with this. This is bad for people who target multiple implementations. Nobody wants to write 5 versions of code because Chicken, Guile, Racket etc each decided to target a different standard, or haven't upgraded to the latest madness from the ADHD-impaired "standardizers" *just yet*. It's also bad for people who target a single implementation, because your code that runs today might no longer run a few years later as the implementation moves on, or the R(x-1)RS support in the implementation starts receiving less support etc. 2007 was a particularly bad year to split a community and waste efforts, as Scheme still had a good chance to be adopted for "modern" stuff (web frameworks, map reduce maybe). Another problem: anything other than a small standard makes it hard to write Scheme interpreters "for everything". This was the amazing thing about Scheme. Want to drive your embedded system? Go ahead and embed a tiny scheme interpreter. Want to drive JVM code? Use KAWA or Sisc. Want to drive an Ocaml program? Embed OCS. R7RS-small might be good, but when lots people write R7RS-large code, and some write R6RS, a lot of code will be useless to minimalistic implementations. Finally, it's sad that this whole disaster was fostered upon the community un-necessarily. There was absolutely nothing wrong with extending Scheme via the SRFI process, particularly on the library side. In fact it was an amazingly effective way to assemble a small, interested community and develop a facility in an organized and controlled manner (as opposed to having a large "electorate" of non-experts trample over everything and argue over bike-shed issues over tens of messages, like a bunch of 'tards). The fact that most SRFI's had reference implementations **in scheme** made it extremely easy to add such facilities to a minimalistic interpreter. In the meanwhile a "big" implementation could write a C implementation of the SRFI. Programs would simply use (require-extension (srfi NN)) and not have to care about such details. Some SRFI's require interpreter support, of course, and users can pressure implementors to "add SRFI NN support" if it's important to them. So I don't think my language was excessively harsh. You really have no idea what you're talking about advocating multiple incompatible standards and huge incomprehensible standards instead of the concise "gems" that R5RS and R4RS were. With people like you on the loose a language can be destroyed (and probably was destroyed, as it's hard to compete with Python nowadays for any language; back in 2007 there was still a a chance to focus on software, not on misguided standards). -----Original Message----- From: John Cowan <[email protected]> To: Giorgio Flaverli <[email protected]> Cc: chicken-users <[email protected]> Sent: Tue, Dec 10, 2013 7:43 pm Subject: Re: [Chicken-users] which RxRS? Giorgio Flaverli scripsit: > I've gradually lost touch with Scheme after the R6RS debacle. It was > a sad day to witness the victory of the pushers of complexity, helped > along by a large number of well-meaning morons who should never have > been allowed in the "electorate" given that they never even came close > to implementing a meta-circular. I wonder how much more successful > Scheme could have been without this disaster and without the harmful > actions of those individuals who caused it. This is excessively harsh and downright insulting language. R7RS-small is, I believe, a substantial improvement over R5RS, but it could not have been achieved so easily and completely without R6RS first paving the way. R6RS provided a model of what standards can aim for as well as what they should not aim for. For example, the R7RS-small committee adopted the R6RS exception-handling system unchanged, but rejected the R6RS condition system because it was backward incompatible with all existing condition systems. The spirit of the R6RS library system informs that of R7RS, though there are differences in detail. A vast number of minor R6RS improvements were added to R7RS-small, leaving out those that we thought would do more to confuse users than to clarify R5RS. Although R7RS-large will not be backward compatible with R6RS, and will be a mix-and-match standard with most components optional, the choices made in R6RS will continue to influence it. Lastly, I was one of those who voted Yes on R6RS, not as an implementer (I am not) but as a user. I favored it not because I thought it was ideal, but because I thought it was a reasonable compromise. All standards are compromises, and the purpose of the process is not to produce the best possible result, but the best result possible in the circumstances. -- John Cowan <[email protected]> http://www.ccil.org/~cowan Today an interactive brochure website, tomorrow a global content management system that leverages collective synergy to drive "outside of the box" thinking and formulate key objectives into a win-win game plan with a quality-driven approach that focuses on empowering key players to drive-up their core competencies and increase expectations with an all-around initiative to drive up the bottom-line. --Alex Papadimoulis
_______________________________________________ Chicken-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-users
