MRI Developers Don't Use RubySpec and It's Hurting Ruby

Hopefully. I would be willing to take a crack at it.

> So many companies are making big bucks off Ruby, yet so little are willing to fork out a bit of money and time to make Ruby better. And why would/should they when there are quite literally dozens (or possibly hundreds or even thousands) of developers who will happily work on "making Ruby better" for no cost to said companies?

A large percentage of software developers will quite happily hack away at projects for nothing in return simply because they enjoy it (and would, quite incorrectly, claim that as compensation itself), in order to gain notoriety, boost their own ego, or any of a number of related reasons.

It's disappointing to hear about such problems with Ruby. I hit the same problem with the Groovy Language spec when I first came across Groovy. Its creator, James Strachan, initiated an implementation, test kit, and spec all within 6 months of each other (impl beta-1 in Dec 2003, and spec JSR-241 in May 2004). The project managers who took over from him, Graeme Rocher and Guillaume Laforge, changed direction by stopping work on the spec and refocusing the Groovy reference implementation to be the scripting language behind Grails. (Of course, Groovy 'n' Grails was intended to chisel away at some of the market share of Ruby on Rails but that's another story.) Strachan often wrote that the spec was to enable anyone to make their own implementation of Groovy if they want to, and right up to his very last posting ever http://groovy.329449.n5.nabble.com/Paris-write-up-tt395560.h... on the Groovy mailing list on 5 Dec 2005, he maintained that what they were building was the reference implementation.

If Rocher and Laforge had come clean about how they turned the RI into the language itself, the backlash might have blown over quickly, but instead they led developers along for many years afterwards, not changing the spec to dormant until April 2012. Projects other than Grails who've tried to build atop Groovy have had to risk the ref impl changing in breaking ways between versions. The most spectacular incident was when Groovy++, an experimental static compiler built by Alex Tkachman that hooked via annotations into Groovy's AST, had to drop back down from Groovy 1.8 to 1.7 in 2011, and my own side project was also affected by the change. It turned out Rocher and Laforge had secretly employed a mate to extend Groovy with the exact same static type-checking and compilation functionality as Groovy++ and were obviously trying to shake us off.

Unlike Ruby, Groovy only has one other implementation, GrooScript, built by Jorge Franco, which generates JavaScript from Groovy syntax. When the developers of the most used implementation of a language want to protect their control, it certainly does hurt the ecosystem, turning it into an "echo system".

Wait, you're saying you'd prefer undocumented bugs and a constant stream of breaking changes to the runtime that force you to constantly port and report existing, working code?

I don't get it... the Java way seems pretty right to me. That said, I will allow that they might have been a little bit too rigid about not allowing breaking changes. At the very least this policy has resulted in Java evolving more slowly than it might have otherwise. But I don't necessarily find that to be unacceptable, all things told.