[haXe] haXe vs Ruby (was : OSCON)

[Richard Kilmer]

On Aug 1, 2006, at 1:57 PM, hank williams wrote:

> Can I just say I love this discussion.
>
> I dont know anything about ruby so I dont have much to contribute,
> other than curiosity.
>
> I am jealous of my friends who code in ruby and describe how easy it
> is to do database stuff. Personally, I code my server side stuff in
> java, but I would love to move to something more modern on the server
> side. I have a little side project that I want to do and I was
> thinking of playing with ruby just to learn. But I would really love
> for the haXe community to be able to crow about DDWS productivity the
> way that the ROR people can.

Where Rails is good is the back end.  Its nice in that its integrated  
with
Prototype to enable AJAX stuff, but if we produced a haXe remoting
capability for Ruby and that could be leveraged by Rails apps then we
could have haXe Flash/JavaScript UIs driven by Rails.

This is the area (btw) that I think haXe could dominate...the user
interface...with the same API crossing Flash, JavaScript and Neko.

-rich

>
> Hank
>
> On 8/1/06, Yariv Sadan <yarivvv at gmail.com> wrote:
>> >
>> > 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
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>
> -- 
> haXe - an open source web programming language
> http://haxe.org