Lynn Winebarger wrote: > So, the official results won't be announced until August 26. > I voted no; my explanation is below. Reading the statements of the > electorate was interesting. I was surprised by how many people > believe popularity is the measure of success in a programming language and > that > the passage of time is in itself sufficient reason to vote for ratification. > I know Will has posted his explanation. Are there any others?
Thanks for your post, which I am very much in agreement with. Here is the explanation accompanying my vote: ---------------------------------------------------------------------- There are several reasons why I am unable to vote in favor of this set of documents. First, I am deeply disturbed by the size and scope of the proposed changes to R5RS. While many of these changes are sensible, there are very many changes, and rather than getting to vote on each change separately, we're forced into voting on all of them at once. This is very like the way national deliberative bodies work, and is even more distasteful in this context. A more incremental process would foster more thoughtful development, allow users and implementers to digest and understand the strengths and weaknesses of each feature before moving on to the next. (I certainly don't have time to fully understand all that is being proposed here.) One interpretation of this process is that it's driven by fear: the fear that the current set of authors have only a limited extent of control over the standards process, and are trying to make the most of it while they can. I don't think that's exactly what's happening here, but I do think there's a certain amount of distrust in the future, based more than likely on the dismal experiences of the past. Nonetheless I think we should start from the assumption that small successes now will lead to more small successes in the future, and that over time those successes will accumulate to make something great. We have to trust our ability to work together, and we have to trust that spreading control of the standards process more broadly through the community is best in the long run. So, what I'm advocating here is something more like the "bazaar" software development model: release early, release often, and be open to participation by the community. The second problem I have is the fairly low priority given to backwards compatibility. This is made all the more important by scope of the documents. I understand that the standard answer to this is that implementations are expected to provide mechanisms for switching between modes -- but this doesn't really address what to do with existing bodies of code. It also makes it more difficult to update existing code to the new language, since there's no incremental update path; each program must be completely transformed all at once, which effectively means it will never happen. Contrast this with ANSI C, for example, in which it's possible to incrementally update programs from traditional to ANSI C, and have them continue to run when only partially updated. This is a huge win that I've taken advantage of in my own code. The third problem I see is that two core features of the language have been designed as entirely new sub-languages: specifically, the module system and SYNTAX-CASE. Not only are these new languages, but they are declarative languages, which makes them fundamentally different from the core language, which has always been imperative. Worse, these sub-languages solve problems that could have been solved by application of the core language, meaning they lead to additional cognitive complexity while getting little in return. The module system is basically a way to tell the linker how to construct programs from parts. Rather than invent a new language to do this, it's possible to build the linker such that the programmer can insert code to control aspects of the linking process. Such code could do _more_ than the current module system does, and because of the added expressivity, it could do so more concisely in many cases. For example, I sometimes use a trivial module system in which names starting with "%" are local, and all other names are exported. This is a trivial program to write, and doesn't depend on the details of the names, but it can't be said at all with the proposed module system. SYNTAX-CASE has similar problems, although not as extreme: it implements a term-rewriting system, with limited programmability, to solve a problem for which there are significantly simpler solutions. This sub-language introduces a new kind of variable that behaves differently from the variables we're used to, and pushes pattern-matching and templating to the center of the macro-writing process. Yet with this added complexity it is arguably no better than the syntactic closures or explicit renaming mechanisms proposed years ago, which have very little cognitive overhead. _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
