[haXe] haXe vs Ruby (was : OSCON)

Yariv Sadan yarivvv at gmail.com
Tue Aug 1 16:18:46 CEST 2006


>
> That is why dynamic languages like Smalltalk have evolved very
> powerful development environments...to help in factoring.  I will
> say, however, having written A LOT of Ruby code that I refactor much
> more often in Ruby than I ever did in Java (of which I wrote A LOT of
> code too) or ActionScript 2.0 for that matter.  Ruby's syntactic
> flexibility inclines me to refactor to "get a better looking API" or
> "meet the domain need" more so than other languages have...although I
> do not want to hold this to haXe since I have not programmed in it as
> much...

>From my experience with Ruby (much less than yours) and haXe, I would
say that haXe lets you break your APIs "lazily" because the compiler
warns you about all the places that need to be fixed. In Ruby, you
need to be more careful when breaking APIs, but in most cases even the
most rudimentary unit tests would warn you about such breakages. My
sentiment is that compiler checks are indeed a nice to have feature
but, as you said, Rails (PHP as well) shows you can write complex
webapps without such checks. When you consider that almost all webapps
-- static or not -- require some unit testing, the gap between
developer effort to validate code with Ruby and haXe diminishes.

> I don't think its a static vs. dynamic but an expressiveness in
> syntax.  Regardless, varying languages are better at some things than
> others...its not that you cannot do the same things in two languages,
> the question is does the language get in the way of the problem you
> are solving or get out of the way.

I agree. Sometimes in static languages you have to construct auxiliary
types such as interfaces and manager objects to approach the
generality and flexibility that are built into dynamic languages. For
example, if you have a collection of objects of different classes that
share common method signatures, static languages require either the
creation of an interface or an inheritence hierarchy. With dynamic
languages, you don't have to worry about creating new types.

I'm not trying to bash static languages -- I'm just bringing up an
advantage to dynamic languages that I find appealing :)


>
> You merely mention ActiveRecord, there is also ActionPack,
> ActionWebService, ActiveSupport, ActionMailer and of course a TON of
> third party plugins.  Rails is a philosophy as much as a framework.
> I am not here to say that the ActiveRecord approach is the only
> approach to wrapping databases.  I am also not saying that Rails is
> the only way to build web sites.  You can build them in anything, I
> just think that Rails has done a hell of a good job of keeping its
> framework focused, clean, and extremely flexibly while maintaining
> high developer productivity.

I think haXe will have such components when it becomes more popular
and developers contribute more code. haXe is much younger than Rails,
and Nicolas spends much of his time on the non-Neko parts.


>
> Yep, and I think the SPOD approach is really sweet, although I think
> that if you dynamically generated the SPOD classes at compile time to
> reduce the duplication of defining types in code and in SQL and
> compile against that dynamically generated code...that or create
> something like Rails migrations that generate those classes for you
> (all fully typed) and the SQL to create the tables it would be nice
> and DRY (don't repeat yourself).

+1

If the compilation/preprocessing was done by the Neko runtime rather
than by the programmer, Neko could generate the code that would allows
us to write Rails-like code such as

class Person extends neko.db.Object {
}

var p = new Person();
p.name = "bob";
p.save();

var people = Person.find_by_name("bob");

without sacrificing type safety. That'll be cool!


>
> Totally agree.  I really think haXe on Flash/Javascript/Neko is
> amazing.  I don't think that you should punt and say "we won't use it
> for X or Y" just because X or Y is seen as having superior support in
> another language.  My question was one of what framework/class of
> problems is haXe specifically suited for that nothing else could
> touch because of its wonderful runtime support.
>
> I have my opinion on this, of course...

I don't know about you, but I'm actually using haXe to build a Google killer :D

Yariv



More information about the Haxe mailing list