Hi all,<br><br>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.<br><br>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.<br>
<br>Again apologies if someone is offended. That it's not my intention.<br><br>Thanks for your patience,<br>Antonio<br><br><br><div class="gmail_quote">2009/9/4 Aaron W. Hsu <span dir="ltr"><<a href="mailto:arcfide@sacrideo.us">arcfide@sacrideo.us</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
On Thu, 27 Aug 2009 03:06:18 -0400, AntonioV <<a href="mailto:antonio.vieiro@gmail.com" target="_blank">antonio.vieiro@gmail.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 26 ago, 19:13, "Aaron W. Hsu" <<a href="mailto:arcf...@sacrideo.us" target="_blank">arcf...@sacrideo.us</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Wed, 26 Aug 2009 06:29:48 -0400, Pascal J. Bourguignon <<a href="mailto:p...@informatimago.com" target="_blank">p...@informatimago.com</a>> wrote:<br>
> "Aaron W. Hsu" <<a href="mailto:arcf...@sacrideo.us" target="_blank">arcf...@sacrideo.us</a>> writes:<br>
>> I think that while Scheme has always been a diverse community, nothing<br>
>> can be gained by creating any schism.<br>
<br>
> Well r7rs is not a schism, since they consider that the large version<br>
> shall be a superset of the small version.<br>
<br>
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.<br>
<br>
</blockquote>
<br>
But, why "resistance to particular pieces"? I don't think any Scheme<br>
user is "resistant" to have a standards-compliant "sockets" (XML/<br>
Threads/etc) library!!<br>
</blockquote>
<br>
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.<br>
<br></blockquote><div><br><br>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.<br>
<br>I think it's important that the steering committee defines *how* consensus is to be reached. Otherwise this is gonna be a nightmare.<br><br>A quick search has pointed me to the "Quaker model":<br><br>"Quaker-based consensus<sup id="cite_ref-Quaker_30-0" class="reference"><a href="http://en.wikipedia.org/wiki/Consensus_decision-making#cite_note-Quaker-30"><span></span><span></span></a></sup>
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."<br><br>I'm not an expert on consensus, but I have a feeling the process to reach consensus should be defined.<br><br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
In fact I do think Scheme uers are *eager* to have a standards-<br>
compliant set of libraries. We've been claiming for that for quite a<br>
long time, I think.<br>
</blockquote>
<br>
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.<br>
</blockquote><div><br>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.<br>
<br>What will happen is that people is going to use Clojure, and newlisp, etc. <br><br>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.<br>
<br>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.<br>
<br>[...]<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
"Working group 2 may also consider whether it is practical to add new<br>
features to support networking, threads, internationalization, foreign-<br>
function interfaces, et cetera."<br>
<br>
So nobody is saying that lots of new features will be added all at<br>
once. There's no hurry. There's a timeline, that's all.<br>
</blockquote>
<br>
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.<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Agreed. This is what I understand it's the goal of working group 2:<br>
make things portable.<br>
</blockquote>
<br>
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.<br>
</blockquote><div><br><br>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.<br>
<br>[...]<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
So maybe the root of the problem is understanding why this happened<br>
with R6RS, to avoid problems with the new one.<br>
</blockquote>
<br>
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.<br>
</blockquote><div><br>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.<br><br><with apologies><br>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.<br>
</with apologies><br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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<br>
</blockquote>
<br>
But, it's the implementations that should adhere to the standard, and<br>
not the standard that should adhere to the implementations!!<br>
</blockquote>
<br>
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. <br>
</blockquote><div><br><br>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).<br>
<br>But the JCP process has defined mechanisms to keep things going. And that's something we should agree upon.<br><br>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.<br>
<br><br>So I think we should make a little effort in decicing how consensus is going to be reached and then go for it.<br><br>For the benefit of the Scheme community!!<br><br><br><br><br></div></div>