The Future of Ruby

From eqqon

(Difference between revisions)

Revision as of 05:04, 9 August 2007

Introduction

Yukihiro Matsumoto's C implementation of Ruby aka Main Ruby Implementation (as time of this writing the stable version of the MRI is Ruby 1.8) is considered the Quasi-Standard of the Ruby Language since there has never been an explicit language standard for Ruby. As the number of implementations grows, however, a formal standard seems to become necessary to prevent the horror scenario of various non-conform interpreters.

The Danger of Diverging Implementations

Microsoft which is is known for their aggressive incompatibility policies is a menace for the Ruby Language in its current form (MRI). In case Microsoft releases Iron Ruby for their .NET platform with intended incompatibilities -- possibly by taking performance optimizations as an excuse -- they will slowly take away Matsumoto's control over the language as more and more .NET developers will use Iron Ruby for scripting in conjunction with .NET languages like C#.

Note that this is only a speculation which is not at all based on any evidence. On the contrary, we have seen Microsoft delivering their "new" language C# as an open standard to the world. Also it should be said, that Microsoft would possibly not have any advantages from incompatibilities as they possibly have from CSS and JScript incompatibilities in their still market-dominating web browser.

Nevertheless there is always the danger of diverging implementations. May it be because Sun Microsystems, an old rival of Microsoft, is actively supporting another implementation for their Virtual Machine called JRuby or may it be for optimizations sake or may it simply be due to Matz not getting Ruby 2.0 released before others, supported by mightier companies, do.

I hope, that the strong and vital Ruby community are aware of these and other future problems the language will face just caused by a missing formal language standard for the current and future versions. I hope they take action soon and eventually write it down.

Interpreter Standardization

There has been quite some effort to document the language's features in the form of books and online reference documentation. Almost all of the language's available documentation can be found on ruby-doc.org. There are still many holes in the documentation which is written by volunteers and it's not formal enough for the development of a ruby interpreter to some extent.

The JRuby folks have started a project called RubySpec which is a formal specification for the implementation of a Ruby interpreter. This documents actually could be developed into a Ruby Standard.

Another quite formal manifestation of the language's features are the unit tests of the MRI. As far as I know they have been used by some of the authors of alternative interpreters. The authors of the Ruby.NET interpreter have also written additional unit tests which are distributed with their source.

Maybe some might argue a written standardization document such as those for C99, ECMA-Script or C# is not necessary or not worth the effort. This is maybe true if it were possible to specify a language in a different but convenient way. Maybe it is enough to provide Ruby's syntax in a way that it could be easily transformed for use with all kinds of different parser generators (i.e. as EBNF grammar) and just extend and define the MRI's testsuite as the formal standardization instrument.

Even if a written formal standard was available that would not prevent non-conformance of interpreters, though. But if it were available right now, non-conform implementations could at least be tagged as non-standard-conform which would be definitely not a desirable demotion for an interpreter. Apart from that, with a standard we would also build a solid base for all different implementations of Ruby and unite all their authors which could in the next step take part in the challenge for defining the future Ruby 2.0 standard.

It seems that the best idea to approach a Ruby Language Standard based on MRI 1.8 would be to utilize all the available unit tests for the Ruby language and transform them into a standardization tool. The RubySpec documents should be revised and maintained by a standardization team consisting of all important authors of ruby interpreters.

Unifying the Ruby Standard Library

Currently every alternative distribution of Ruby is maintaining their own standard library. This obviously leads to various problems which also emerge from "copy-pasting" code in a program. Updates in the standard library will have to be merged into each implementation. Bugs will have to be fixed separately multiple times. Again, divergence of implementations is a result of all this. Applications depending on the standard library will have to check for the platform they are running resulting in undesirable code constructs like this:

switch RUBY_PLATFORM 
when "JRuby"
    # fixes for JRuby
when "Ruby.NET"
    # fixes for .NET
when "IronRuby"
    # fixes for IronRuby
default
    # code for MRI or unknown platform
end

Such constructs will not be completely avoidably in some cases but they should really not have to be in user code. They should be implemented in a single instance of the standard library which should be factored out of MRI and transformed into an interpreter-independent standard library. Some of the standard library modules are native extensions which cannot be separated from their specific interpreter implementation but that should not keep us from unifying the pure ruby parts of the standard library.

Ruby Standardization Group

It cannot be denied, that in the advent of multiple alternative Ruby implementations for different platforms there will be a great need for some explicit standardization activities and it is about time to do something.

The first step could be to call for people who feel responsible for standardization (i.e. the authors of MRI and other implementations) and form a standardization group. Apparently the inventor of Ruby, Yukihiro Matsumoto, should be the head of this group which will then decide what actions to be taken.

Links

Interpreters

Currently there are quite a lot different implementations of Ruby1.8 which are more or less complete. We will take a look at the most important and complete ones.

Ruby (MRI) The main implementation.
JRuby An almost complete implementation of the interpreter in Java.
YARV A virtual machine in C which has been merged into MRI 1.9.
Ruby.NET Still incomplete and unoptimized .NET compiler for Ruby.
Rubinious A not well known implementation based loosely on the Smalltalk-80 VM architecture.
Iron Ruby - The implementation by Microsoft for .NET has not yet been released.

@@ Line 47: / Line 47: @@
 == Links ==
-=== Interpreters ===
+;Interpreters
 Currently there are quite a lot different implementations of Ruby1.8 which are more or less complete. We will take a look at the most important and complete ones.
-* [http://www.ruby-lang.org/en Ruby (MRI)]
+* [http://www.ruby-lang.org/en Ruby (MRI)] The main implementation.
-* [http://jruby.codehaus.org/ JRuby] A very complete implementation of the interpreter in Java.
+* [http://jruby.codehaus.org/ JRuby] An almost complete implementation of the interpreter in Java.
 * [http://www.atdot.net/yarv/ YARV] A virtual machine in C which has been merged into MRI 1.9.
 * [http://plas2003.fit.qut.edu.au/Ruby.NET/ Ruby.NET] Still incomplete and unoptimized .NET compiler for Ruby.
-* [http://rubini.us/ Rubinious] An implementation based loosely on the Smalltalk-80 VM architecture.
+* [http://rubini.us/ Rubinious] A not well known implementation based loosely on the Smalltalk-80 VM architecture.
-* <b>Iron Ruby</b> This implementation by Microsoft has been presented but not yet released.
+* Iron Ruby - The implementation by Microsoft for .NET has not yet been released.
-=== Ruby 1.9 ===
-* [http://www.davidflanagan.com/blog/2007_08.html#000131 List of differences between 1.8 and 1.9 by David Flanagan]