The Ruby Draft Specification
Having a formal specification of what makes a language “Ruby” is a good idea. It gives us a lexicon which makes things easier to discuss (for e.g. metaclass vs. eigenclass, plus the operators <=> and « have a dozen different names). It also goes a long way towards proving that Ruby is a mature language that anyone can adopt; and I think it would make people more comfortable.
That being said, in the intro to the draft specification (available at http://ruby-std.netlab.jp/) they announce the draft is based on Ruby 1.8.7, not Ruby 1.9. The reason they give is:
Ruby 1.9 is moving fast and its features change frequently. Once we draft the specification based on Ruby 1.9, the specification and Ruby 1.9 would get quickly out of sync.
There’s a problem in that statement. Languages change. They morph and flex to meet the needs of the developers they serve. Any spec based on a language should have a flexible enough process to be able to change with the language. Ruby 1.9 would be the perfect test case for this project. Since it does change it would allow the spec team to find ways to handle those changes. Beyond that, the 1.9 release shows the direction Ruby is taking as a language. Therefore, it is much closer to what 2.0 will look like than 1.8.7. Changing the spec to match 2.0 would be much easier if they started from where 1.9 is today and ignored 1.8.
The spec exists to help the language and the community using it. If you start out with an approach that doesn’t handle quick changes then your spec will likely lose its utility. We embrace change in all other parts of the development process, why not here too?
