[haXe] haXe vs Ruby (was : OSCON)

Nicolas Cannasse ncannasse at motion-twin.com
Tue Aug 1 09:39:56 CEST 2006


Let me state my point of view on this subject, which has went a bit far 
from the original topic.

Ruby itself is a dynamicly programming language with good OO support. 
While it surely is more powerful than other languages of this kind (PHP, 
Python...), it is dynamicly typed. That means that everytime you make a 
significant modification in your program (renaming a class, a method, or 
adding an argument for example) you will have to manually go through 
your whole code to be sure you changed everything accordingly.

The two other possible approachs are to run your application or write 
unit tests for it but you can't be sure that either your manual or 
automatic testing will cover every case, and hence detect errors like a 
strict compiler would. Also, in a web app, testing complex interactions 
is almost impossible to automate.

OTOH, haXe is staticly typed. Some people are arguing that this is a bad 
thing, since it "prevent programmers from expressing themselves". That 
is particulary true with Java but fortunately, haXe is not Java. Some 
people tend to generalize the Ruby VS Java choice into a Dynamic VS 
Static debate, without knowing what other staticly typed languages have 
to offer. In particular, with haXe type inference you can get the same 
expressiveness level as a dynamicly typed programming language without 
giving up the compile-time typing security (see my OSCON slides for an 
example).

Having used both kind of languages for a long timer, I'm convinced that 
the haXe approach permits better productivity in the middle term, 
especially for applications/websites that you need to often modify and 
improve, even during the development cycle when architecture constantly 
evolves...

Rails uses Ruby expressiveness to give the programmer a powerful way to 
wrap database tables into Ruby classes. haXe has a similar thing called 
SPOD (http://haxe.org/tutos/spod). The main difference between SPOD and 
Rails is that you will have to declare your database fields with types 
into your class in SPOD. That's the small price to pay to get a 
completely typed program. Also, there are of course some language 
differences between the two. Since Rails really uses Ruby at its best, 
SPOD is doing the same with haXe.

Although SPOD doesn't support all Rails features - since it hasn't been 
designed as a Rails challenger - there is no reason it can't be further 
improved with additional things. For typing reasons, it's true that 
extending SPOD with additional features is not an easy task, since you 
have to think about both the result you want to get at runtime AND the 
typing you want to get at compile time... and they should match :)

The question at this point would be : which improvement do your need ? 
Just debating over "potential" of a given library doesn't make so much 
sense, unless you actually need/use the features it provides.

Nicolas



More information about the Haxe mailing list