[ruby-core:32620] Re: Proposal for Optional Static Typing for Ruby

Hi,

Martin Pilkington wrote:
> 
> So why should Ruby get this?  Well the best way to answer that is
> to describe some of things that languages with some degree of
> static typing have.  The first off is pre-runtime checking of
> code.  Have you misspelt a method or a variable?  Did you call a
> method on an object but forget to implement it?  These things can
> be warned of before you run your code, and they can also be run
> over your entire code.  Related to this is general static
> analysis, where while not only checking for syntax errors, it can
> also check for common bugs and inform you about code paths that
> are never run, either because they aren't needed and you haven't
> yet removed them or because you're not doing something correctly.
>
> Then you have editing tools such as refactoring and autocomplete.
> Refactoring can be much more reliable if it knows what types it is
> dealing with.  If you wanted to rename a method for example, there
> may be similarly named methods on multiple classes which are
> called throughout your code, but you only want to rename the calls
> on instances of your object.  And autocomplete becomes more than
> filtering a list of method names that have the same prefix as what
> you have currently typed, if it knows the class of the object
> you're calling the method on then it can severely narrow that
> down, and often provide you the correct result first time, meaning
> less typing.

Contrastingly, my (essentially) only interest in static typing
is where it can improve performance.

Is everyone familiar with the approach Charles Nutter has
taken with his Mirah language (formerly Duby)?

http://www.mirah.org/
http://www.mirah.org/wiki/MirahSamples

There's a compelling example in the rubyconf video at 15:45
http://rubyconf2009.confreaks.com/21-nov-2009-14-10-ruby-mutants-charles-nutter.html
where a Mirah program is diff'd against the Ruby version of
the program, and they're almost identical.  Yet, the Mirah
version runs with native floating point performance.

A caveat would of course be that the program is a simple
benchmark geared toward computation with native types and
nothing else.

Which is true; but on the other hand it is just this sort
of code where it can be especially desirable to achieve high
performance.

Anyway; to clarify: I realize Mirah itself is not Ruby, nor
is it intended to be Ruby.  But what intrigues me is that
it demonstrates it's possible to have a language that looks
like Ruby, with very minimal extra clutter from type
declarations, and achieve 'native' performance on routines
dealing with native types.


Regards,

Bill