The guy leading Microsoft's port of Ruby to .NET has warned of a potential Balkanization of Ruby, which could impair the language's success.
http://www.regdeveloper.co.uk/2008/04/24/ruby_balkanization_john_lam
This is a stronger wording on the same theme from the same guy (John Lam) as a story about a month ago on the Register which I commented on here.
I'm wary (maybe too wary) of the possibilities of Balkanisation of Perl 5. I remember richardc having a lot of pain with a bug report that he couldn't replicate for one of his modules - turned out in the end that the end user's perl reported itself as "5.8.1" but was actually "5.8.1 RC3", and RC3 had the bug, whereas vanilla 5.8.1 did not. This is one reason why I'm very reluctant to bump maintenence version numbers until close to the release - even if it's an intermediate version, anything claiming to be 5.8.$n but actually a bit more recent should have no new bugs, and some old bugs fixed, whereas if the same executable reported itself as 5.8.$n + 1 then it may not have all the bugs fixed that the true 5.8.$n + 1 release has, leading to much wailing and gnashing of teeth. I'm not happy if people ship a perl that happens to have more command line options, because unknowing users will assume that they are standard, add them to their #! line, and if the program is migrated to another OS, they will assume that the breakage is a bug in Perl, and we look bad. So I added a test that all unknown options remain unknown :-). And I'm not totally comfortable when distributions ship 5.8.x with syntax changing patches such as the defined-or patch, as that, again, could lead to "Perl" programs that work here, but fail with a syntax error there. Although at least the defined-or patch is well written, and makes its presence known in -V.
So it's reassuring to know that Perl 6 starts out with a single strong test suite (which it sounds like @Ruby is only just getting to), as that will reduce fragmentation. Plus, recently a new face, John M. Dlugosz, appeared on Perl 6 Language, and is working hard to hammer out the ambiguities in the Synopses to make them proper specs.
On the down side, I note that Ruby has 5 funded implementations, whereas Perl 6 has about ý a funded Perl 6 implementation, and 0 funded Perl 5 implementations. (And, grr, when I asked for feedback on the viability of a plan on trying to raise that figure, Perl 5 Porters digress away from helpful things like "try it" or "this specific is bad, this alternative might be better". Whereas they are perfectly happy to digress off topic discussing another Register Ruby FUD story. Does The Register have something against Ruby?)
Meanwhile, to Balkanise properly, Ruby would need an implementation without vowels, an implementation that has a dispute about its name because it's too much like the name of a module in a neighbouring language, and an implementation that fragments out of a (perceived as core) module in an existing implementation.
I presume that Richard's problem would have gone away if the user had used -V to get his version information instead of -v?
I ask for -V when people submit bug reports about Devel::CheckLib, cos that also tells me about the compiler and stuff. I suppose I should ask for -V for all bug reports.
