I'm sympathetic to Bear's position and frustration. My "yes" vote on R6 was, as I tried to say with my vote, motivated largely by the thoughts that (a) it wasn't going to get any better under the process at hand; (b) ratification would enable the community to lick its wounds and move on.
I hoped that two things would follow ratification: 1) R6RS believers would start cranking out the holy grail of "lots of useful libraries," -- the much anticipated phenomenon that would supposedly make Scheme as practical for many as, say, Python, Perl, and Ruby are today. 2) R6RS critics would converge on a real "correctional" -- make an alternative Scheme. With all due respect, neither has much occurred. There are few signs of life. As to libraries, most everyone seemed to assume that an unnamed host of "others" would step up to supply them given a new module system. As to a correctional, the slow but continuing progress on ERR5RS notwithstanding, my impression from the dialog is that few R6 dissenters have the economic resources to spend much time on it, much as we'd like to. I notice that the only recently finalized SRFI is for environment variable access. Nothing wrong with that but that's a short list. I notice only two draft SRFIs, one to standardize an R6 naming convention for SRFI libraries, the other a records proposal coming out of ERR5RS. Both fine proposals, I'm sure, but a dismally short list. There has been some progress on implementing R6 including one new implementation. I am not aware of any significant advances in implementation techniques. I'm not certain what conclusions to draw from this but I do have some speculation: Except for a small number of academic positions and a small number of niche industry positions, there appears to be no money to be made using Scheme, never-mind working on improving it. In contrast, it appears that a critical mass of commercial adopters of Perl, Python, Java, and similar languages formed *before* those languages developed large libraries and community-driven language improvements. The commercial interest drove the development of those libraries, for the most part. Now, today, Scheme is handicapped for commercial adoption by the lack of libraries and so the libraries of those other systems constitute a "barrier to entry" for any new and improved Scheme. In retrospect, R6 started very, very late in the game applying a tactic (developing a module system) that "should" have been done at least a decade earlier. The effort to add a module system was premised, roughly speaking and informally attributing motive, to Steele's notion of a "growable" language and with faith that "if you build it they will come." Well, it got built. They didn't come. (As an aside to Bear: More than a decade ago Guile Scheme attempted to introduce and promote a module system that, while not perfect, was at least practical and flexible enough to grow into a more principled solution. That work was done with commercial support and that commercial support also disrupted that work and denigrated it at a critical juncture, delaying progress on it for years, just when and perhaps even because of the then recently pre-announced Oak, soon dubbed Java and (then) taken to be the crown prince of client-side programming on the web. Bear: in my experience, bitterness of the sort you evince does not fade much with time and the intellectual vindication of seeing people realize their mistakes far after they are willing to do anything like admit and correct them is quite a hollow victory.) Perhaps we have reached a kind of "end of history" in the domain of dynamic languages. Javascript and Python, and to a lesser extent Ruby and Lua appear to be the focus of most attention. There is money in them. There is strategic positioning for them (e.g., Javascript in browsers; Python at Google). By some kind of "power law" of economics, it might be unreasonable to expect Scheme to gain much adoption at all, anytime soon. Frighteningly, commercial forces will probably continue to align to thrust some incremental improvement to JVM down our throats as the One True Run-time System API, even further constraining any innovation in dynamic languages. Without monied adoption of Scheme, it is hard to imagine that we'll have a lively and productive community cranking out libraries and having productive debates about how best to improve the core language. Yet without an improved core and lots of libraries, monied adoption lies nowhere in sight. Scheme, folks, appears to be a sad and obscure victim of the obscene excesses and rush-to-build-out of the dot-com boom. People around my age might get my drift if I put it that: Scheme is the new Pascal only without even a "Turbo" implementation around. It's the kind of language you might use for teaching, as a case study: similar enough to "real world" languages to be educational yet simple enough for students to dissect or assemble. If these speculations are right, the situation can not be improved by revising the standard. To be sure, as a matter of simple maintenance, it strikes me as a good idea to replace the steering committee. They wish to step down and so the community choice is either to give up the pretense and go without a steering committee entirely, or to replace them with their kind assistance. If we replace them, there is a ghost of a chance. And, to be sure, again just as a matter of routine maintenance, an eventual R7 or substantially similar follow-up is desirable, if we can muster it. R6 would make a poor, sad coda to the series. As a matter of respect for our belief in the good work and good ideas that are our community heritage, at the very least, at least one more less problematic document is desirable. I would like to propose some theses, based on these observations, though I doubt I can come up with 95 of them just now: 1. The role of a steering committee is unconstrained. The next steering committee is not limited to appointing editors and initiating an R7 process. 2. To advance the Scheme language meaningfully requires more than an R7. To become "relevant" other than as a historic expression of certain ideas -- that is, to become "practical" or to be a "tool" for engineering -- Scheme needs compelling applications. 3. Nothing in the R_RS series is sacred other than, perhaps, a commitment to recognizably traditional lisp-ish types, s-exp notation, lexical scoping, closures, continuations, and a dedication to providing some powerful form of syntactic abstraction. I.e.: there is nothing "sacred" to Scheme in the R_RS series that isn't already found in the Rabbit thesis and "Lambda the Ultimate..." papers. Scheme remains, at heart, a set of ideas that aim to describe a practical approach to building practical systems using a few famous "tricks". 4. Scheme (thus understood) is superior, in principle, to its real-world competitors. It suffers in the real world from under-funding, ultimately. The ideas need to be realized in a commercially compelling form for a broad audience if we are to raise the bar for dynamic languages. Scheme is very well suited as a starting point for doing so. 5. The next steering committee should formalize and sanctify its status by seeking funding assistance sufficient to create a non-profit corporation with a self-nominating board which is distinct from the steering committee itself. The bylaws of this NPO should define a form of membership sufficient that the membership elects the steering committee and the steering committee normally controls operations, but the board may step in to override. While the board should be self-nominating, it should be chartered such that signifcant details of its expenditures are public record and such that periodic "confidence votes" are solicited from the membership and the results made public record. (These public records are for the benefit of the membership, the board, and current and potential sponsors.) 6. Simultaneously, the next steering committee should develop, in a transparent fashion and soliciting suggestions from the community, a series of proposals for fund-able, free software projects which aim to help bootstrap far greater real-world adoption of Scheme, including commercial adoption. Each project proposed should include a contribution to an eventual R7. An eventual R7 should include *at least* one official reference implementation. 7. The new board and steering committee should engage in fund-raising, primarily but not exclusively from potential corporate sponsors, to hire staff to work on those proposals. The net effect would be to create a kind of semi-democratic, non-profit, Institute for the Advancement of Scheme. I'm not sure there is any lesser hope worth aiming for. -t On Mon, 2008-11-03 at 10:19 -0800, Ray Dillinger wrote: > On Mon, 2008-11-03 at 12:23 -0500, Marc Feeley wrote: > > > I meant divergent opinions on the "soul" of Scheme and on the goals. > > In other words fundamentally divergent opinions on Scheme and the > > design process. The message(s) from the SC to the EC must be clear > > and direct. That will simply not happen if there is discord at the SC > > level. Divergent opinions are good, and necessary, as long as the SC > > members are comfortable in discussing the issues to converge on a > > common position, but fundamentally divergent opinions will kill the > > process. I believe the EC can tolerate more divergence of opinion. > > Here too it can be a problem that stalls the process, but the SC can > > step in in those cases. > > I see in R6RS a repudiation of the spirit of Scheme - and also > a poor standards document. > > In part this was because there was insufficient effort to > respond to divergent opinions or to draft a general standard > suitable for implementing scheme on diverse platforms. Ideas > for resolving conflicts got ignored without technical response > as the processed rushed to adopt specific proposals. The > standard itself was passed while still containing known errors > and inconsistencies. > > There was an opportunity to create a document that specified a > (drastically simplified) "core scheme" and pushed all controversial > items out to libraries which are, in principle separable and > interchangeable. This was not done. The "core language" > specified in R6 is not simpler and contains many controversial > elements that could have been placed in libraries. The library > of functions is monolithic, inseparable, and there is no way > to create any alternatives to any part of it. This is not just > a failure, it is an epic failure. And no amount of effort > seemed capable of convincing any of the editors that there was > any better way to do things. > > In this process, I felt that whatever input I (and several others > whose design sense I respect) made was ignored or treated as a > mere obstacle. I was frustrated with the process and I am > unsatisfied with its result. I am not emotionally ready to repeat > the investment of work at this time, and I do not feel that such > an investment of work would be very likely to give better results > at this time. Moving into the process, as I would, on the defensive, > still stinging with frustration, and with reduced expectations that > good ideas will actually be listened to, would not make me a "nice" > person to work with and would be unlikely to elicit my best > standards work. > > Also, I feel that it's necessary for its supporters to have enough > time to take new positions. I don't want them defending Bad > Ideas merely because they defended them before and can't > stomach admitting that they were wrong. I think they need a > year or two more to first understand and then get over how badly > they screwed up. > > As far as I'm concerned, R6RS was a waste of effort on my part > and I don't want to touch it again until I'm pretty sure the > rest of the world has fully appreciated its flaws. Only with > that realization will people be truly ready to try and fix it > and future effort less likely to be wasted. > > Bear > > > > _______________________________________________ > r6rs-discuss mailing list > [email protected] > http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
