That's basically how I read this. It seems that Ruby is specified de facto by what MRI does.
Reading this blog post it sounds like the developer of RubySpec did this:
1. Decided Ruby needed more formal specification
2. Made their own formal specification
3. Kept telling the core developers to use it
4. Is giving up after years of the core developers not bending to the way he thinks that Ruby should work
The whole thing just read as kind of arrogant to me. Why should the ruby developers have to follow his specification? The fact that there is a bug that causes a segfault only indicates there is a bug, I don't see it as an indictment of the core language process.
Instead of saying "you should be using my test", you could commit mew tests and patches to upstream. If some of the existing tests or two large or don't test only one function, why not submit a patch to fix those issues. That doesn't mean the entire test week needs to be thrown out and the language respecified.
This seemed more like someone trying to force themselves into a position and giving up after a few years.
> 1. Decided Ruby needed more formal specification 2. Made their own formal specification
RubySpec isn't a formal specification in any way, shape or form. RubySpec is an implementation test suite, and for MRI a regression suite. It uses language constructs and expects a behaviour A based on Ruby version B (which is itself assumed to match MRI version B).
RubySpec isn't somebody thinking up his own definition of Ruby (let alone doing so formally), it's somebody encoding MRI behaviour into a test suite because he needed that to code his own Ruby implementation.
> Why should the ruby developers have to follow his specification?
There's nothing to follow, there's a test suite to run. A test suite which encodes existing MRI behaviour. Why should ruby developers run it? Because it catches bugs is a pretty good reason.
> The fact that there is a bug that causes a segfault only indicates there is a bug, I don't see it as an indictment of the core language process.
How is segfaulting on existing code not an indictment of the core process when just running an existing test suite would have caught it?
> Instead of saying "you should be using my test", you could commit mew tests and patches to upstream.
Have you missed the laundry sheet of issues in the existing MRI testing system?
The problem with "MRI as spec" is that nobody really knows how the language is defined.
E.g. large parts of the 1.8.x series behaved differently from what most people thought it did in terms of the bootstrapping of inheritance of core classes. I wrote a blog post about Ruby behaviour based on introspecting the 1.8.6 interpreter that some people insisted was wrong because it worked differently than intended. Yet the behaviour persisted for years until it silently changed at some point (I don't know which revision).
In that case it was no big deal since the reason the real behaviour was pretty much unknown was that nobody depended on the behaviour, but from what I've seen this is fairly common with MRI.
As a "spec" it is one of the most unstable environments I've worked with. Though I love Ruby the language, MRI is a problem as the default implementation and atrocious as a "spec".
I frankly hope one of the other implementations gains enough traction to force the core team to the "negotiating table" over a proper specification.
Reading this blog post it sounds like the developer of RubySpec did this:
1. Decided Ruby needed more formal specification 2. Made their own formal specification 3. Kept telling the core developers to use it 4. Is giving up after years of the core developers not bending to the way he thinks that Ruby should work
The whole thing just read as kind of arrogant to me. Why should the ruby developers have to follow his specification? The fact that there is a bug that causes a segfault only indicates there is a bug, I don't see it as an indictment of the core language process.
Instead of saying "you should be using my test", you could commit mew tests and patches to upstream. If some of the existing tests or two large or don't test only one function, why not submit a patch to fix those issues. That doesn't mean the entire test week needs to be thrown out and the language respecified.
This seemed more like someone trying to force themselves into a position and giving up after a few years.