Global Mindshare Domination

Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary. Scheme demonstrates that a very small number of rules for forming expressions, with no restrictions on how they are composed, suffice to form a practical and efficient programming language that is flexible enough to support most of the major programming paradigms in use today.

Over the years I have become peripherally involved in the work of developing standards for the Scheme community. I am by no means a major contributor, but I do have an ongoing interest in the language and the systems that have been built to run it efficiently.

Once upon a time I was a SRFI editor, and I participated in the voting on R⁶RS. Today (2007-08-16), it looks as if R6RS is going to be standardized. Given the R⁶RS charter, the ratification process and the votes, I don't see that there can be any other outcome that does not violate the rules for approving the new standard document. This is unfortunate because there are several serious problems with the standard. They are largely outlined in the no votes; however, there are several yes votes that also indicate problems. I won't repeat the verbage of those who are either smarter or more involved in the process than I am here, except to say that I am very surprised that people cited my opinions as being relevant.

Now today (2007-08-25) I have been pointed to the notes from the discussion which started this whole process. And they are very interesting. It is nowhere near as democratic as people seem to think ([1], [2]), but on the other hand, there appears to have been a definite intention to push the community into places it may not have wanted to go ([3], [4], [5]) and what looks to me like an endorsement of "Worse is Better" as a language design philosophy. As Brian Harvey pointed out way back in 1991, this may actually have been a predictable outcome.

All of the politics are not particulary relevant to the overriding issue of havong a high-quality technical document. At least I am not particularly opposed to the growth in the size of 'Standard' Scheme, as long as it has been done in a way that is consistent with the principles outlined by Will Clinger (above) and is technically sound. That is not the case and is clearly shown in the votes (and other parts of the ongoing discussion). Given the political foundations of the process, it is possible and maybe even desirable for the Steering Committee to intervene .

This is probably even more true if you consider the use of Scheme in Computer Science education. There is a significant tension between practical features and theoretical elegance which has been a hallmark of Scheme for quite a long time. However, it seems that in recent years, the trend in CS education has been towards more practical work and less theoretical. In my opinion, This is a bad thing. For one it promotes really bad engineering , but the real problem, as Brian Harvey implied, is that knowing the tool-du-jour is very different from knowing the structure of a large class of tools. The beauty of Scheme is that it has reified the structure of a truly huge range of tools into a fairly simple programming language.

Now because of Turing completeness, we know that, beyond certain minimal limits, it is foolish to speak about the 'expressive power' of computer languages - nevertheless we do find very real, and very practical, esthetic differences between languages. I, and others, would argue that Scheme not merely balances the expressive power and pedagogical simplicity, but that the necessities of teaching CS theory through Scheme have made it an excellent language for delivering solutions. Apparently many students (and the faculties which live off their tuition fees) do not feel that way anymore. Too bad. As R. W. Hamming argued in his book Numerical Methods for Scientists and Engineers, students aren't really qualified to know how they should be taught. And the corporate world is structurally unable to understand (much less adopt) a good tool when it becomes available. I think that the larger point is simply that following the crowd is a losing strategy. It certainly is not the way that Scheme became the language it is today.

So to summarize, I fully believe that the R^5.97RS draft should not be ratified, no matter what the votes say. Maybe this is bad sportsmanship on my part, but I prefer to think it is because we should be working towards something better than a mere community consensus (which process was not even put in place by the community!). There are even technical and procedural reasons for not approving the current draft above and beyond what I have outlined here. It is not up to the technical standard of either R⁴RS or R⁵RS, and that is what will ultimately determine the uptake by the community. Or alternatively, a language specification split which will be no less legitimate than R^5.97RS.