Ruby is an elegant language created to fill the need for a truly object-orientated scripting language. A new language was needed because you can't just tack objects onto a language and it be object-orientated. Object-orientated is a way of thinking, and Ruby is likewise, a way of thinking.
In learning Ruby, learning the thinking is not the hardest part. It's the giant brick wall of capabilities that's the problem. If you know more than one programming language then you may not necessarily need to learn all new concepts of programming, just a new syntax and a new API. When that API begins to multiply and drill down into hundreds, and then thousands of methods, classes and objects, where do you begin?
Reading the documentation isn't always the solution when there's hundreds of classes and you don't know the name of the one you need. What if the solution you need is a class that's only returned by a method of another class? Learning Ruby [for me at least] is like being a rabbit, frozen in the middle of the road with the bright lights of functionality beaming at you.
Certainly classic ASP is easy to knock, but the language has so few functions that you can piece together those primitive tools to build what you need, learning ingenuity yourself through solving simple string manipulation problems for example.
Ruby is a language where to begin with, all that ingenuity has been done for you. Somebody has already solved that text problem with a string method, or library - you need only to drag yourself through the painful procedure of finding it.
That said, what tiny experience I have with Ruby, it is a fun language. It trips off the keys and dances across the screen almost like poetry.
So why the need to fork ruby?
Why does any project need to be forked, for that matter? Is it not because a project becomes too many things for too many people and it no longer has that one hammer, one nail design to problem solving?
The keynote demonstrates how Ruby has grown, adopting solutions to problems so much that the programmer creates his solutions with methods, rather than with syntax, to the point there's many more than one way to skin_a_cat.rb.
Indeed, here's where I get back on track. Some problems cannot be solved with more methods and classes -- without in essence practically implementing a new language on top of Ruby itself. No, it's syntax that is the bricks and mortar, and methods are just the decorations.
Syntax, despite the very un-English look of it, is much easier to remember than methods. Ever sat there at the end of a period thinking of the method you need? You didn't have any problem remembering the dot though.
The need to play with the syntax is a running theme throughout the keynote. Methods cannot solve the parallel problem - "If you do it with the current syntax and semantics, you'll be struggling with the integration of global variables, the non-threadsafe nature of require, continuations, and so on, and so on." Dave notes in his blog post linking to the keynote.
When dealing with a big project used by many thousands of people, of course you'd want to maintain backwards compatibility or at least not break things too much between minor revisions. Dave asserts though that the locking up of the syntax prevents people from playing with solutions to fundamental problems that cannot be achieved through methods alone.
You can design and improve stairs a thousand ways, but eventually you'll have to rethink things to invent the elevator. If Ruby needs to change direction, that cannot be achieved on mainline trunk. It is just too large and too slow to swing the ship around. Dave is proposing a number of smaller "scout ships" go ahead and find the way.
Parallelism is tomorrow's problem, today. We are coming across a chasm of performance as individual processor speeds come to a standstill and cores begin to multiply.
Despite our every ability to create parallel solutions, the syntax isn't there. The hardware can be designed and crated to be parallel, yet we can't wrap our minds around an easy way for us to declare to that hardware our intentions.
Dave notes something very elegant about parallelism. We've had the answer all along. The equals sign is parallel, it always has been. We've just not been making use of that capability of the equals sign to express parallelism.
If we want to solve the problem of spreading solutions across multiple cores easily, we need to be able to instruct the computer easily and not get bogged down in methods and classes and programming structures to do this. Can you imagine trying to program a parallel solution in PHP?!
The "Cluby" example demonstrates the syntax elegance problem by pointing out something that's technically possible already, but people don't do it simply because of syntax. Their behaviour is being guided away from an elegant solution because it's not beautiful to look at. Syntax has to be art, and you cannot produce art if your tools create ugly results even when used skilfully. No amount of talent will make a brick a good choice of brush.
Why are keywords special things? Why is `if` not a function itself? You could say that 'how can `if` be a function when you would need `if` itself in order to implement it? Impossible!'. It's a syntax problem. The syntax has not been there to remove these special case keywords from programming languages in general. Even Ruby, therefore, falls short of perfection by falling prey to interpreter-specific special case keywords.
Keywords are procedural. "Cluby" is the first time I’ve seen this problem explained so easily. If I could invent a language, it would be "Cluby", because I believe the programmer is smarter and more importantly-more artistic than the machine, and solutions should be constructed using syntax rather than forcing the artist's hand with keywords and methods.
The downside though of course is syntax soup. LISP, Perl -- both powerful, syntactically descriptive languages, but difficult to read.
There must be something wrong with us all, or we are simply not being taught correctly, if SmallTalk did this all a long time ago, and yet we are not all SmallTalk programmers. Why do we even have any procedural languages still around?
Clearly then, even after 50 years of general-purpose computing we still haven't come up with the answer to the final language to describe it all.
If we cannot categorically define art, then we will also never define computer programming once and for all. But why should we define it once and for all, when it's all supposed to be about enjoyment anyway? Or has it just become about the money, such as art has said to become? Never should that be!