[haXe] haXe vs Ruby (was : OSCON)

[Luzifer Altenberg]

Hallo

I dont think its all about Ruby but Rails. Rails is well done in all  
aspects modern web apps.
you can say the same about Django (djangoproject.com) which is  
written in python.
a simlilar framework written in haXe would have many advantages over  
both of them
since haXe is typed, compiled and faster?.

The database abstraction  layer of django looks more like SPOD since  
it uses
Managers like haxe SPOD. And the DB columns are members  of the model  
class.
(in django they are Instances of a Class so they include type  
information and other information like length, autoincrement...
that makes it possible to craete the database out of the model and  
vice versa)

so what would I need in SPOD.

Validation
many to many relations
pre and post save/update callbacks
migrations (on of the cooles features rails offers , DB version  
management in ruby code)
pagination (not realy related to SPOD)
some artimetic features (SUM ; AVG, COUNT , ...)

other than that I think haXe would need a package manager/ 
distribution system like
ruby gem or python eggs.

also since haXe is quite new some basic things are missing

- open ssl (https)
- SHA1...
- easy mail (send via SMPT with auth or sendmail, POP, IMAP)...
- image manipulation
- SOAP
- XMLRPC
- YAML
- RSS/ATOM reading/writing
- pdf generation
- pack , unpack (for easy binary data manipultaion)
......


Luzifer


















On 01.08.2006, at 09:39, Nicolas Cannasse wrote:

> 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
>
> -- 
> haXe - an open source web programming language
> http://haxe.org