|
All of the above = a huge bag of hurt that presents some damn near insurmountable problems (leadership, on its own, is a huge issue). To be honest, I don't know how one would get past those things without first deciding, with a clear conscience, to hijack Ruby from Matz. I know that sounds malicious, but even Dave Thomas is calling for a fork of the language. Seems to me that forking is not quite what we need, as it keeps the language rooted in the past, bringing the performance baggage with it (you're still having to re-implement the loose idea of the Ruby spec, which as you pointed out, presents some really hard problems). No, maybe we need someone smart, loud, and with balls big enough to arbitrate their way through whatever gray areas are left with Ruby's loose idea of a spec, perhaps make some tough calls on what language features can reasonably be supported, decide what needs to be cut, and break compatibility with existing Ruby code if necessary. To top it off? This person forms a foundation around it, a la Python.org, to ensure that the language is left in good hands, gets proper funding for new development, patches, etc (hell, I would love to donate to Ruby development if I knew the money would be put to good use. I don't have that confidence now). Of course, what I'm talking about now is not Ruby, but a new thing. This new thing could be quite awesome. Whatever this new thing would be is still years out, even if someone decided today that they would do it. Python in the meantime? |
There's a massive gulf between Matz and Guido as far as decision making, even when you only look at the Languages and not their imperfect Implementations. Just for example, look at how executable objects work:
* Guido made a hard+pragmatic decision that there are only Functions. Methods and Class Methods are functions that take their binding as an explicit argument (which is inferenced when called with the . selector). Lambdas cannot contain statements and simply yield to a Function. Functions are recursively defined as objects with a __call__ method.
* Matz tried to make everything hugs all around and the result is that there's no straightforward Function type -- there are Methods, Blocks, Procs, Lambdas (1); which yield into one another bafflingly and retain scope in untoward ways. This makes some simple use cases very straightforward, but at a terrible cost.
(1). Are there more? The lack of certainty with which I can answer this question is alarming.