The Future of Ruby
From eqqon
m (→Introduction) |
|||
| Line 1: | Line 1: | ||
== Introduction == | == Introduction == | ||
| - | Yukihiro Matsumoto's C implementation of [[Ruby]] aka ''' | + | Yukihiro Matsumoto's C implementation of [[Ruby]] aka '''M'''ain '''R'''uby '''I'''mplementation (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 multiple concurring incompatible interpreters. |
| - | + | Microsoft which is currently working on Iron Ruby and is known for their aggressive incompatibility policies is a menace for the Ruby Language in its current form (MRI). In case that Microsoft release Iron Ruby for their .NET platform with severe incompatibilities -- possibly by taking performance optimizations as an excuse -- they will slowly take Matsumoto's control over the language away as more and more .NET developers will use Iron Ruby. | |
| + | Note that this is only my speculation which is not based on any evidence or rumor. On the contrary, we have seen Microsoft delivering their new language C# as an open standard to the open source community. Also it should be said, that Microsoft would possibly not have any advantages from language incompatibilities as it has from CSS and JScript support incompatibilities in IE. | ||
| - | + | Nevertheless there is always the danger of diverging implementations. May it be because Sun Microsystems which is an old rival of Microsoft is supporting an implementation for their Virtual Machine (JRuby) or may it be for optimizations sake because Ruby is comparatively slow to other languages or may it simply be due to Matz' not getting Ruby 2.0 released before others which are supported by mightier companies do. | |
| + | |||
| + | I hope, that Ruby's strong Open Source community are aware of these and other future problems caused by a missing formal language standard and take some effort in writing it down, derived from the current stable MRI version. | ||
| + | |||
| + | There has been quite some effort to summarize the language's features in the form of developers reference documentation. Most of the language's available documentation can be found on [http://www.ruby-doc.org/ ruby-doc.org]. There are still many holes in the documentation which is mostly written by volunteers and it is to some extent not formal enough for the developers of a ruby interpreter. | ||
| + | |||
| + | A quite formal documentation of the language's features are the [http:// (link still missing) unit tests of the MRI]. As far as I know they have been used by some of the authors of different interpreters. The authors of the Ruby.NET interpreter have also written additional unit tests which are distributed with their source. (TODO find all available test resources). | ||
| + | |||
| + | It seems to me that the best idea to a '''Ruby Language Standard''' would be to analyze those available unit tests and of course the parser-grammar of the MRI and transform them into a formal specification for the Ruby Language with the goal to create a solid base for all different implementations of Ruby and unite all their authors which could take part in the challenge for defining the Ruby 2.0 standard. | ||
== Ruby Implementations == | == Ruby Implementations == | ||
| - | Currently there are | + | 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://jruby.codehaus.org/ JRuby] A very 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. | ||
| + | * <b>Iron Ruby</b> This implementation by Microsoft has been presented but not yet released. | ||
| - | === Ruby 1.9 === | + | === Ruby 1.9 / 2.0 === |
* [http://www.davidflanagan.com/blog/2007_08.html#000131 List of differences between 1.8 and 1.9 by David Flanagan] | * [http://www.davidflanagan.com/blog/2007_08.html#000131 List of differences between 1.8 and 1.9 by David Flanagan] | ||
Revision as of 09:35, 7 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 multiple concurring incompatible interpreters.
Microsoft which is currently working on Iron Ruby and is known for their aggressive incompatibility policies is a menace for the Ruby Language in its current form (MRI). In case that Microsoft release Iron Ruby for their .NET platform with severe incompatibilities -- possibly by taking performance optimizations as an excuse -- they will slowly take Matsumoto's control over the language away as more and more .NET developers will use Iron Ruby. Note that this is only my speculation which is not based on any evidence or rumor. On the contrary, we have seen Microsoft delivering their new language C# as an open standard to the open source community. Also it should be said, that Microsoft would possibly not have any advantages from language incompatibilities as it has from CSS and JScript support incompatibilities in IE.
Nevertheless there is always the danger of diverging implementations. May it be because Sun Microsystems which is an old rival of Microsoft is supporting an implementation for their Virtual Machine (JRuby) or may it be for optimizations sake because Ruby is comparatively slow to other languages or may it simply be due to Matz' not getting Ruby 2.0 released before others which are supported by mightier companies do.
I hope, that Ruby's strong Open Source community are aware of these and other future problems caused by a missing formal language standard and take some effort in writing it down, derived from the current stable MRI version.
There has been quite some effort to summarize the language's features in the form of developers reference documentation. Most of the language's available documentation can be found on ruby-doc.org. There are still many holes in the documentation which is mostly written by volunteers and it is to some extent not formal enough for the developers of a ruby interpreter.
A quite formal documentation of the language's features are the [http:// (link still missing) unit tests of the MRI]. As far as I know they have been used by some of the authors of different interpreters. The authors of the Ruby.NET interpreter have also written additional unit tests which are distributed with their source. (TODO find all available test resources).
It seems to me that the best idea to a Ruby Language Standard would be to analyze those available unit tests and of course the parser-grammar of the MRI and transform them into a formal specification for the Ruby Language with the goal to create a solid base for all different implementations of Ruby and unite all their authors which could take part in the challenge for defining the Ruby 2.0 standard.
Ruby Implementations
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)
- JRuby A very 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 An implementation based loosely on the Smalltalk-80 VM architecture.
- Iron Ruby This implementation by Microsoft has been presented but not yet released.