The Future of Ruby - Revision history

Henon: /* The Danger of Diverging Implementations */

2007-11-11T14:05:54Z

The Danger of Diverging Implementations

← Older revision		Revision as of 14:05, 11 November 2007
Line 5:		Line 5:
	None of the alternative implementations that are currently developed are yet complete and totally MRI conform. The stable MRI version is also continuously changed due to bug-fixing and improvements of the standard library. All alternative implementations are leaping behind the MRI and all the behavior changing fixes will have to be promoted to the alternative implementations in order to stay conform to MRI. Currently there is no explicit synchronization or standardization process to support this.		None of the alternative implementations that are currently developed are yet complete and totally MRI conform. The stable MRI version is also continuously changed due to bug-fixing and improvements of the standard library. All alternative implementations are leaping behind the MRI and all the behavior changing fixes will have to be promoted to the alternative implementations in order to stay conform to MRI. Currently there is no explicit synchronization or standardization process to support this.

-	Microsoft has shown aggressive non-conformance policies in the past and is an old rival of Sun Microsystems. Both companies are developing alternative Ruby interpreters. It is possible that Ruby developers will be faced by the same problems as Java developer were, back then when Microsoft and Sun both provided mutually incompatible implementations of Java. In case Microsoft would again try to pull the same trick and release Iron Ruby for their .NET platform with '''intended incompatibilities''' -- possibly by taking performance optimizations as an excuse -- this would result in coding horrors for authors of pure Ruby applications and libraries which should run on both MRI and IronRuby. The greatest hope, however, is that Microsoft would probably not have any advantages from releasing IronRuby not conform to MRI because Ruby is not (yet) a market-dominating language.	+	Microsoft has shown aggressive non-conformance policies in the past and is an old rival of Sun Microsystems. Both companies are developing alternative Ruby interpreters. It is possible that Ruby developers will be faced by the same problems as Java developer were, back then when Microsoft and Sun both provided mutually incompatible implementations of Java. In case Microsoft would again try to pull the same trick and release Iron Ruby for their .NET platform with '''intended incompatibilities''' -- possibly by taking performance optimizations as an excuse -- this would result in coding horrors for authors of pure Ruby applications and libraries which should run on both MRI and IronRuby. The greatest hope, however, is that Microsoft would probably not have any advantages from releasing IronRuby not conform to MRI because Ruby is not (yet) a market-dominating language. (Remark: IronRuby has been released to the open source community in Autumn 2007. At time of this writing, however, it was not yet clear what Microsoft would do with it.)

	Nevertheless there is always the danger of diverging implementations. May it be for optimization's sake because Ruby code is hard to optimize due to its heavily dynamic nature or may it simply be due to the uncoordinated development processes of the different interpreters.		Nevertheless there is always the danger of diverging implementations. May it be for optimization's sake because Ruby code is hard to optimize due to its heavily dynamic nature or may it simply be due to the uncoordinated development processes of the different interpreters.

Henon: /* Interpreter Standardization */

2007-08-10T10:52:34Z

Interpreter Standardization

← Older revision		Revision as of 10:52, 10 August 2007
Line 12:		Line 12:

	== Interpreter Standardization ==		== 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 [http://www.ruby-doc.org/ 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~~.	+	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 [http://www.ruby-doc.org/ ruby-doc.org]. There are still many small holes in the documentation which is written by volunteers. Though these documentation resources are good enough for ruby developers they are not formal enough for the development of a ruby interpreter.

-	The JRuby folks have started a project called [http://www.headius.com/rubyspec RubySpec] which is a formal specification for the implementation of a Ruby interpreter. This documents actually ~~could~~ be developed ~~into a~~ Ruby Standard.	+	The JRuby folks have started a project called [http://www.headius.com/rubyspec RubySpec] which is a formal specification for the implementation of a Ruby interpreter. Later, the Rubinious crew and volunteers started to join in and formed it into a quite good language specification. This documents actually should be further developed and revised and declared as the official "Ruby Language 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~~.	+	Another quite formal manifestation of the language's features are the '''unit tests''' of the MRI and other implementations. They should be united, revised and declared as the official "Standard Ruby Language Tests".

-	~~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.	+	Such standardization tools would be a solid base for all different implementations of Ruby and unite their authors which could in the next step take part in the challenge for defining the future '''Ruby 2.0 standard'''.
-		+
-	~~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 ==		== Unifying the Ruby Standard Library ==

Henon: /* Ruby Standardization Group */

2007-08-10T10:39:39Z

Ruby Standardization Group

← Older revision		Revision as of 10:39, 10 August 2007
Line 42:		Line 42:

	== Ruby Standardization Group ==		== 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.	+	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. This seems to be the best way to coordinate and organize standardization activities.
-		+
-	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~~.	+

	== List of Interpreters ==		== List of Interpreters ==

Henon: /* List of Unit Tests for the Ruby Language */

2007-08-10T10:34:17Z

List of Unit Tests for the Ruby Language

← Older revision		Revision as of 10:34, 10 August 2007
Line 57:		Line 57:
	== List of Unit Tests for the Ruby Language ==		== List of Unit Tests for the Ruby Language ==

-	* JRuby's tests are at http://svn.codehaus.org/jruby/trunk/jruby in the test dir.	+	* JRuby's tests are at [http://svn.codehaus.org/jruby/trunk/jruby] in the test dir.
-	* Rubinius's specs are at http://code.fallingsnow.net/svn/rubinius/trunk	+	* Rubinius's specs are at [http://code.fallingsnow.net/svn/rubinius/trunk] in the spec dir.
-	in the spec dir.	+	* RubyTests is at [http://rubyforge.org/projects/rubytests]
-	* RubyTests is at http://rubyforge.org/projects/rubytests	+

Henon: /* List of Unit Tests for the Ruby Language */

2007-08-10T10:33:04Z

List of Unit Tests for the Ruby Language

← Older revision		Revision as of 10:33, 10 August 2007
Line 54:		Line 54:
	* Iron Ruby - Another implementation for .NET by Microsoft (has not yet been released).		* Iron Ruby - Another implementation for .NET by Microsoft (has not yet been released).
	* [http://www.atdot.net/yarv/ YARV] A virtual machine in C which has been merged into MRI 1.9. The YARV project itself is no longer maintained.		* [http://www.atdot.net/yarv/ YARV] A virtual machine in C which has been merged into MRI 1.9. The YARV project itself is no longer maintained.
		+
		+	== List of Unit Tests for the Ruby Language ==
		+
		+	* JRuby's tests are at http://svn.codehaus.org/jruby/trunk/jruby in the test dir.
		+	* Rubinius's specs are at http://code.fallingsnow.net/svn/rubinius/trunk
		+	in the spec dir.
		+	* RubyTests is at http://rubyforge.org/projects/rubytests

Henon: /* Introduction */

2007-08-10T10:31:03Z

Introduction

← Older revision		Revision as of 10:31, 10 August 2007
Line 1:		Line 1:
	== Introduction ==		== Introduction ==
-	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 various non-conform interpreters.	+	Yukihiro Matsumoto's C implementation of [[Ruby]] aka '''M'''ain '''R'''uby '''I'''mplementation 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 ==		== The Danger of Diverging Implementations ==

Henon: /* The Danger of Diverging Implementations */

2007-08-09T05:46:33Z

The Danger of Diverging Implementations

← Older revision		Revision as of 05:46, 9 August 2007
Line 3:		Line 3:

	== The Danger of Diverging Implementations ==		== 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#~~.	+	None of the alternative implementations that are currently developed are yet complete and totally MRI conform. The stable MRI version is also continuously changed due to bug-fixing and improvements of the standard library. All alternative implementations are leaping behind the MRI and all the behavior changing fixes will have to be promoted to the alternative implementations in order to stay conform to MRI. Currently there is no explicit synchronization or standardization process to support this.

-	~~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~~.	+	Microsoft has shown aggressive non-conformance policies in the past and is an old rival of Sun Microsystems. Both companies are developing alternative Ruby interpreters. It is possible that Ruby developers will be faced by the same problems as Java developer were, back then when Microsoft and Sun both provided mutually incompatible implementations of Java. In case Microsoft would again try to pull the same trick and release Iron Ruby for their .NET platform with '''intended incompatibilities''' -- possibly by taking performance optimizations as an excuse -- this would result in coding horrors for authors of pure Ruby applications and libraries which should run on both MRI and IronRuby. The greatest hope, however, is that Microsoft would probably not have any advantages from releasing IronRuby not conform to MRI because Ruby is not (yet) a market-dominating language.

-	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~~.	+	Nevertheless there is always the danger of diverging implementations. May it be for optimization's sake because Ruby code is hard to optimize due to its heavily dynamic nature or may it simply be due to the uncoordinated development processes of the different interpreters.

-	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~~.	+	I hope, that the strong and vital Ruby community are aware of these and other problems the language will face in the near future all caused by missing standardization and synchronization activities.

	== Interpreter Standardization ==		== Interpreter Standardization ==

Henon: /* Links */

2007-08-09T05:07:30Z

Links

← Older revision		Revision as of 05:07, 9 August 2007
Line 46:		Line 46:
	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.		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~~ ==	+	== List of 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.		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)] The main implementation.		* [http://www.ruby-lang.org/en Ruby (MRI)] The main implementation.
	* [http://jruby.codehaus.org/ JRuby] An almost 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://plas2003.fit.qut.edu.au/Ruby.NET/ Ruby.NET] Still incomplete and unoptimized .NET compiler for Ruby.
	* [http://rubini.us/ Rubinious] A not well known 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.
-	* Iron Ruby - ~~The~~ implementation ~~by Microsoft~~ for .NET has not yet been released.	+	* Iron Ruby - Another implementation for .NET by Microsoft (has not yet been released).
		+	* [http://www.atdot.net/yarv/ YARV] A virtual machine in C which has been merged into MRI 1.9. The YARV project itself is no longer maintained.

Henon: /* Links */

2007-08-09T05:04:48Z

Links

← Older revision		Revision as of 05:04, 9 August 2007
Line 47:		Line 47:

	== Links ==		== 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.		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://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://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]	+

Henon: /* Ruby Standardization Group */

2007-08-09T05:01:48Z

Ruby Standardization Group

← Older revision		Revision as of 05:01, 9 August 2007
Line 41:		Line 41:
	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.		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.

-	== ~~Summary~~ ==	+	== Ruby Standardization Group ==
-	~~Anyway~~, in the advent of multiple ~~clones of the MRI~~ for different platforms ~~I see~~ a great need for some explicit standardization activities ~~by Ruby's open source community. Whether they will write a document comparable to other formal language standards or find their own "Ruby Way" is not so important~~ and ~~left open for discussion by the community. But~~ it is about time to do something, ~~isn't it?~~	+	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 ==		== Links ==