At 22:59 09/01/05, Michael Klishin wrote:

>It would require a shift in perspective about the process though. My  
>observations so far (3+ years with Ruby)
>are that Ruby people are a bit like children (in a good sense, and  
>myself included). They like playing and not necessary like keeping  
>things organized.

Very well put. Also, the whole PEP business doesn't exactly match
agile development. From http://agilemanifesto.org/:
- Individuals and interactions over processes and tools 
- Working software over comprehensive documentation
Sometimes, it's important to think something through very well
and to have everybody agree. Sometimes, it's important to fix
something quickly. For some things, there are only very few
people who care, or who understand what's involved. Sometimes
(often), it's easier or more important to actually try things
out than to describe them in detail.

For some changes, in particular for the move to Strings tagged
with Encoding when going from 1.8 to 1.9, there have been
very detailled wiki pages, but they were less formal than
PEPs, and they were in Japanese.


>Python people are more "boring", and this is why IMO they have PEP  
>and really well thought out process of 2.5 => 3.0 migration,
>  and we don't have REP and any 1.8.x => 1.9.x migration plans. I am  
>not bitching/complaining here, I just want to say, this would be a way  
>more significant move for Ruby community that a switch from Subversion  
>to Git. This is it.

Another difference is that Python is basically monolingual (only English),
but Ruby development is bilingual (Japanese and English). Currently,
this seems to work reasonably well for bugs: People have an idea
of who might be responsible for a bug, and accordingly post in English
or Japanese. Most Japanese developers read English well enough to feel okay
with English bug reports (a good bug report usually has very little text,
and lots of data).

For PEP-like proposals, my guess is that it would be quite a different
story. Abstract text takes quite a bit more time to read and digest
in a foreign language, and proposals tend to be way longer than bug
reports.

Code is one way to lower language barriers!

A third point is that the Ruby community doesn't have an unlimited
amount of resources (read: people). It's not just a question of
doing REPs or not doing REPs, but of doing REPs or doing something
else (such as testing, bug fixing, additional features, better docu,...).

My conclusion is that something REP-like could work for some aspects
of Ruby development, but expecting that every change in the language
is documented by a REP is going way too far.

Regards,    Martin.



#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst / it.aoyama.ac.jp