The problem is that RubySpec isn't used to TDD cross-implementation features. It isn't a "specification" so much as a reflection of what MRI does.
The Rubinius team's complaints (though hyperbolic) still stand. Developing features in MRI and then testing other implementations against that is not a good design process. It makes sense for historical reasons, but there is significant work to be done cleaning out the cruft of Ruby.
I had no idea the main ruby implementation uses plain old bison instead of a hand written parser, but what exactly is wrong with that? If anything having all the grammar rules already spelled out means another implementation can just reuse them, there are bison-like tools for almost any language.
Over half of those lines are a hand written lexer. The grammar is basically useless without the lexer, which is very complex, full of weird corner cases, and changes version by version.
And much of it, in both the lexer and the grammar rules, is very heavily tied into MRI internals.
I think Brian "ending" Rubyspec might end up being the best thing he's done for it. Suddenly, as soon as he (and Rubinius) left, RubySpec is running and actively used on MRI for the first time in years, and JRuby and Opal have already swapped over to the new implementation. @eregon deserves HUGE credit for making this all happen.
Perhaps the best thing Brian ever did for RubySpec might be pouring a significant chunk of his life into starting and maintaining the project? Whatever you think of the politics, the value RubySpec has now is in large part due to him, and very likely wouldn't be around for someone else to pick up now if he hadn't invested so much into it.
Now that MRI is using it and others have picked up where he left off, the work done before is realizing its true value and is finally fulfilling the original goal. Quitting was the catalyst for change that may have never occurred otherwise. Perhaps both were very important.
It’s a decent summary, but—as someone who was part of the team back when we started the project—the goal of RubySpec was always to be the test suite and specification of the Ruby language, and for the Ruby community. It wasn’t about Rubinius, and it wasn’t an afterthought.
I’ve been out of the Rubinius (and Ruby) scene for several years now, so I can’t speak much to the rest… but unfortunately the personality clashing seems sadly familiar.
I'm really glad to see this - RubySpec is a project that always seemed like a Really Good Idea, but the politics around it seemed to drag it down into not-productive territory. If it can remain a technically-focused project, it should be a large asset to the Ruby community.
I am sad that the Rubinius team won't join, but I understand that they have seen it all crumble before, and don't want to invest in a time draining project again.
I'd also like to see some funny or surprising differences between the implementations, it could be fun to have a list of that somewhere.
Rubinius doesn't want to join is not because they don't want to invest the effort, they actually invested a lot of efforts before.
That being said, they bring up this project more for political reasons, that they want to control the language, e.g.
If MRI fails on the rubyspec, whose fault is that? It would be MRI if rubinius controls the project.
Now rubyspec is part of the ruby (MRI) project, and they have made a lot of changes to conform MRI, and in return rubinius would need to adjust to conform the specs, for a project that has 24K commit and still doesn't work on windows, you can imagine why they don't want to join effort.
Free as in price (and why would the draft be free if it didn't differ), can it be redistributed freely? Not to mention the gcc extensions that are essentially required because so many applications rely on them.
If the C language standardization process is anything like the C++ standard, then there are no changes between the final, elected draft and what is published. The drafts have to have near unanimous support between Europe and the US (organizations, universities, and groups from each region get one combined vote). Here's a trip report from the C++14 final draft, https://isocpp.org/blog/2014/02/trip-report.
They are the same because they go into an ISO certification meeting with the goal of reaching an unanimous, that is over 90% agreement, acceptance of the entire document with over a hundred people voting in that meeting.
You can't expect that if there's going to be surprised changes.
(Source: Strousup explained this at a recent dev conference)
The Rubinius team's complaints (though hyperbolic) still stand. Developing features in MRI and then testing other implementations against that is not a good design process. It makes sense for historical reasons, but there is significant work to be done cleaning out the cruft of Ruby.
For a sample of such cruft, please refer to the 11k+ line "parse.y": https://github.com/ruby/ruby/blob/trunk/parse.y
Done this way, all other implementations are held back by the early mistakes of MRI and there is little incentive for MRI to change that.