From: "Martin J. Dürst" Date: 2013-01-04T16:40:13+09:00 Subject: [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.