On Fri, 04 Sep 2009 05:49:29 -0400, Antonio Vieiro
<[email protected]> wrote:

> 2009/9/4 Aaron W. Hsu <[email protected]>
>
>> On Thu, 27 Aug 2009 03:06:18 -0400, AntonioV <[email protected]>
>> wrote:
>>
>>> 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.

Sometimes we want different kinds of consensus for different parts. We
probably don't need the same type of consensus for an OpenGL interface as
we would for Core Scheme. Separating out the different components allows
different rules to be applied for managing the standards.

>> 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.

This isn't a problem that you solve by standardization. It is solved by
writing good libraries! People have these libraries written, but they are
hard to find sometimes. I'm working on that problem, and I'll have
something for the community to test in regards to that shortly. :-)

People shouldn't blame the lack of standards for a lack of libraries. They
just need to start writing libraries.

        Aaron W. Hsu

-- 
Of all tyrannies, a tyranny sincerely exercised for the good of its
victims may be the most oppressive. -- C. S. Lewis

_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss

Reply via email to