Hi all, Lots of criticism in the way things work in this email. I don't intend to offend anyone. I'm just trying out to make Scheme succeed, because I do really like Scheme.
And I think it's the right time to make my small voice be heard. Just in case it's of any use for the future of Scheme. Again apologies if someone is offended. That it's not my intention. Thanks for your patience, Antonio 2009/9/4 Aaron W. Hsu <[email protected]> > > On Thu, 27 Aug 2009 03:06:18 -0400, AntonioV <[email protected]> > wrote: > > On 26 ago, 19:13, "Aaron W. Hsu" <[email protected]> wrote: >> >>> On Wed, 26 Aug 2009 06:29:48 -0400, Pascal J. Bourguignon < >>> [email protected]> wrote: >>> > "Aaron W. Hsu" <[email protected]> writes: >>> >> I think that while Scheme has always been a diverse community, nothing >>> >> can be gained by creating any schism. >>> >>> > Well r7rs is not a schism, since they consider that the large version >>> > shall be a superset of the small version. >>> >>> I don't think that the bigger standard causes the schism because it could >>> be a different language; as you have said, it won't be, per se. I think the >>> schism will result from an all or nothing attitude, and that that nature of >>> a single large specification will make it difficult to move forward given >>> resistance to particular pieces. >>> >>> >> But, why "resistance to particular pieces"? I don't think any Scheme >> user is "resistant" to have a standards-compliant "sockets" (XML/ >> Threads/etc) library!! >> > > Oh yes they will. Most in fact. It isn't that they wouldn't like to have a > standard library, it's that they don't like what others think they should > have as a standard api. It takes a long time for some of the features to > reach a point of consensus. Arguably, there are a lot of things in R6RS that > could have been made better if they could have been left for longer > discussion. It was because everything had to be "pushed out the door, that > we ran into trouble. > > I think this is an important issue to address. Requiring consensus to define a standard API (not a standard implementation of that API, though) is going to be difficult and is going to take a long time as you say. I think it's important that the steering committee defines *how* consensus is to be reached. Otherwise this is gonna be a nightmare. A quick search has pointed me to the "Quaker model": "Quaker-based consensus<http://en.wikipedia.org/wiki/Consensus_decision-making#cite_note-Quaker-30>is effective because it puts in place a simple, time-tested structure that moves a group towards unity. The Quaker model has been employed in a variety of secular settings. The process allows for individual voices to be heard while providing a mechanism for dealing with disagreements." I'm not an expert on consensus, but I have a feeling the process to reach consensus should be defined. > On things that the community agrees on, let's go ahead and get those things > out and standardized. On things that the community is divided on, such as > the right sockets library, the right way to handle threads and concurrency, > the right way to do modules and such, let's spend some time figuring out how > to do it right, and not rush it. > > In fact I do think Scheme uers are *eager* to have a standards- >> compliant set of libraries. We've been claiming for that for quite a >> long time, I think. >> > > Yes, they are eager, but they are not eager to have a *bad* set of > libraries. That's what will happen if we try to force things to standards > that don't have well accepted solutions. THe problem isn't the desire to > come together, it's that few people agree on the right way to do things. > Then, again, that's *the* problem. If we don't have a set of libraries (even though they're "not that good") then what would happen is that people is going to use less powerful languages, and that the future of Scheme will ruined. What will happen is that people is going to use Clojure, and newlisp, etc. And that MIT will start using Python or Perl instead Scheme for teaching new grads. Just because of the libraries. Because it's important for new grads to learn how to use libraries and, what's even more important, how to use *bad* libraries and how to *decide* why a library is bad. Libraries are the future of computer science (including *bad* libraries) even if we don't like it. And people will do that even though Perl or Python or Clojure do not have "excellent" libraries. The quality of the library does not matter. It is more important to have the library ready and to be able to do things. For the sake of Scheme's future. [...] > > "Working group 2 may also consider whether it is practical to add new >> features to support networking, threads, internationalization, foreign- >> function interfaces, et cetera." >> >> So nobody is saying that lots of new features will be added all at >> once. There's no hurry. There's a timeline, that's all. >> > > It's just not efficient to have Working Group 2 doing all this stuff. I'm > arguing for a paradigm shift in order to make the community better able to > produce good standards in a timely fashion that help us in the way I think > is least likely to create bad results. > > Agreed. This is what I understand it's the goal of working group 2: >> make things portable. >> > > However, you also need to make sure that the quality of the interfaces is > as good as they can be. Lot's of things can be made portable very quickly by > making bad, ad hoc design decisions. Doing so will ruin Scheme. > Then, again, I think this is not the case. I think the future of Scheme depends on the things you can do with Scheme. And the things you can do with Scheme depends on the libraries available. The standard libraries that are available. I may want to use an implementation on Windows and then another on Unix (and that's ok) but I don't want to use a library on Windows and then another on Scheme. That's an implementation detail I should not worry about. That's what Python or Perl or Clojure provide. And that's exactly what's missing in Scheme. [...] > >> So maybe the root of the problem is understanding why this happened >> with R6RS, to avoid problems with the new one. >> > > I think the root of the problem was that R6RS tried to do too much. It > didn't make it possible to adapt and be dynamic. It was an all or nothing > type of standards process. It introduced new, untested interfaces, and had > to compromise on numerous features that were not ready to be standards. > So the problem was the mechanism used to reach consensus. The steering committee should then define which mechanism is going to be used, to have things on time. <with apologies> Alternatively the steering committee could impose a set of libraries and become a benevolent dictatorship, and do not try to reach consensus through a formal mechanism (they could, though, listen to the community). Benevolent dictatorship seems to work well in many open source communities out there. </with apologies> > > My proposal for a better approach is to make it possible to implement as >>> many standards as possible without forcing the implementations to use ones >>> that they don't want. If they could cherry pick, this would at least >>> >> >> But, it's the implementations that should adhere to the standard, and >> not the standard that should adhere to the implementations!! >> > > That's not the way reports should work. The Scheme community doesn't > operate on a top down approach where standards are handed down by the powers > that be. Instead, the traditional, successful approach has been to recognize > established practices and interfaces from the community and adapt them as > standards. The implementations are the place to do the initial hot testing > of a feature to see how well it works and what the problems are. As these > features become more and more widespread, they can be standardized. > Well, ok. That's the way the Java Community Process works, for instance. Java vendors, Java users and whoever wants (Scheme implementors and users) group together in a working group to define an API (that they can later on implement in different ways). But the JCP process has defined mechanisms to keep things going. And that's something we should agree upon. Anyway I wouldn't say the "traditional way to do things in the Scheme community" has been very successful. R6RS has not been very successful (from what I heard/seen around) and MIT moving to Perl (or was it Python? ;-)) has not been very successful either. So I think we should make a little effort in decicing how consensus is going to be reached and then go for it. For the benefit of the Scheme community!!
_______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
