[haXe] haXe vs Ruby (was : OSCON)

[hank williams]

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.

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
>