Are there more appropriate mailing lists you could have this discussion on? Would you like some help with Chicken Scheme?
-a On Tue, Dec 10, 2013 at 07:08:19PM -0500, Giorgio Flaverli wrote: > @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 <[1][email protected]> [2]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 > > References > > Visible links > 1. mailto:[email protected] > 2. http://www.ccil.org/~cowan > _______________________________________________ > Chicken-users mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/chicken-users -- my personal website: http://c0redump.org/ _______________________________________________ Chicken-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-users
