[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