This morning, when following links to Jamie Cansdale’s ongoing tiff with Microsoft (best of luck, Jamie) I came across Martin Fowler’s concerns about Ruby on .NET. Most of the responses I’ve seen have – entirely reasonably – been about Microsoft’s relationship with open source and with the community as a whole. All of that is fine, but two points particularly caught my attention in Martin’s post:
Soon-to-be-ThoughtWorker Ola Bini, a JRuby committer, reckons that it’s almost impossible to figure out how to implement a Ruby runtime without looking at source code of the MRI – but Microsoft imposes drastic limitations on its employees’ ability to download open source software, let alone look at the source.
and
The overwhelming sense I heard in the community was not “Ruby will kill evil Microsoft” but “how can we overcome the problems to get Ruby on Microsoft.”
Now, as a disclaimer, I’ve done virtually no Ruby. I reviewed some early drafts of Ruby For Rails, and I’ve heard wonderful things about it from my ThoughtWorker friend Stuart, but I haven’t used it. As such, I certainly am in no position to judge it as a language in terms of elegance, power etc.
However, the first quote above raises a concern. My reading of it is that unless you look at the MRI, you don’t know how Ruby is meant to behave, and thus can’t implement it. Frankly, that puts me off the language a bit. I’m all for the agile idea of only documenting when it really adds a benefit, but surely specifying how a language is meant to behave is a real benefit. Now, I know there will always be kinks in languages where sane developers wouldn’t use the corner cases, but those developers who have used them really want them to work on every implementation, but I would hope those can be documented at the same time. Heck, there are plenty of details like that in C#, for instance.
This also answers the second quote I’ve included – what the community can do to overcome the problem of getting Ruby onto the .NET platform. If one of the main problems is that the team can’t look at the MRI source code, and currently the MRI source code is the only way of understanding how an implementation should behave, then surely changing the latter state of affairs would overcome the problem and help the rest of the community at the same time. Microsoft changing its interaction with the open source world would also overcome the problem, but in some ways that’s irrelevant – it in no way stops the community from writing a fully-fledged Ruby spec.
My concern when writing this is that this world is full of very smart people, and Martin’s obviously one of them, so I guess I’ve missed something. I’ve seen that there are some projects to specify Ruby’s behaviour, but if these projects are going well then that should make John Lam’s task more feasible, and if they aren’t then that would call into question either the Ruby community’s desire to see Ruby on .NET or its competence to actually get a spec together. Having watched a small part of the process of getting Groovy adequately specified, I know it’s a lot easier said than done, but even so…
So, what am I missing?