[ruby-core:51238] Re: [CommonRuby - Feature #7549] A Ruby Design Process

Hello Brian,

On 2013/01/01 6:33, brixen (Brian Ford) wrote:
>
> Issue #7549 has been updated by brixen (Brian Ford).
>
>
> I've written another post addressing many of the misunderstandings about my proposal expressed in this thread:
>
> http://brixen.io/2012/12/30/a-ruby-design-process-talking-points

This says:

 >>>>
The proposed design process attempts to reduce as much as possible the 
need for all implementers to discuss proposed language features. The 
discussion occurs after clear documentation is written, after precise 
RubySpecs are written, and after everyone implements the feature so that 
it passes RubySpec. The discussions then focus on concrete facts about 
the impact of the proposed feature to existing and future code, whether 
it is in libraries, frameworks, or applications.
 >>>>

This is the part of your proposal that I understand least (there are 
other parts that I disagree quite strongly with, but at least I think I 
understand why you proposed them).

What's the point of discussion if all implementations have already 
implemented the feature? Discussion makes much more sense to me in the 
early stages of some idea. Often somebody has an idea, but it's not 
complete. There are many cases of feature proposals in redmine that 
don't give all the details because the proposer hasn't figured out all 
of them. But nevertheless, many of these proposals (of course not all) 
have a lot of merit. One very clear category is where Matz has already 
agreed with everything except that we are still missing a really good name.



Creating and evolving a programming language is a creative process. Such 
a creative process is messy and takes time. Putting it in a process 
straightjacket doesn't help.

This creative process is also where Matz is way ahead of everybody else. 
He has been working on it for 20 years, and the results so far have been 
to everybodys liking.

Giving every Ruby implementation the same weight of opinion may be 
appropriate when it comes to implementability questions. Every serious 
Ruby implementation has an established track record on implemenatability 
issues. But when it comes to language design issues, nobody can in any 
way match Matz's track record on language design.



At the end of your post, you write:


 > The proposed design process seeks to create these three things:
 > 1. A definition of the Ruby language that is independent of any
 > particular implementation of Ruby.

That wouldn't be a bad thing to have.

 > 2. A definition of Ruby that is explicit and verifiable by running
 > RubySpec.

I think you also know that executable specs/tests are never able to 
verify/prove that an implementation is correct/conformant. So this is 
just impossible, unfortunately.

 > 3. A process of deciding what features are in the Ruby language that
 > is fair to all implementations of Ruby.

See above for this point. Fairness to implementations is appropriate for 
implementability concerns (see e.g. the recent feedback from Charles 
Nutter on implementation problems with refinements, which resulted in 
quite some changes). Fairness to implementations isn't very relevant 
when it comes to general language design issues.


Regards,    Martin.