Are you already using haXe?

[FFighter]

Well, I´m not yet. But it only seems to be a matter of time until a put my hands into it. The language seems beautiful, the framework too. I would like to use it in all my enviroments but I can´t as I heavily rely on PHP framework such as CakePHP for the server side application-server. For Flash, however, I guess I will switch to it when my current project is done and will start porting ARP/ARPX for learning purposes.

haXe has many different aspects that change the way we think about web development, bringing an additional abstraction layer but offering all the flexibility and performance we need. Well, at least its what I think it is as I didn´t use it yet ;)

So, what you guys think about it? Are you already using it? Do you plan to use it? I definetly do!

If you haven´t heard of it before, take a look at the site: http://www.haxe.org, it is being developed by the same person behind mtasc (Nicolas Canasse) and already got a quite active developer community (see the mailing list).

Cheers,

Marcelo.

[newblack]

that looks amazing- not using it currently though...

[FFighter]

Yes, it really looks promising :)

[[Sx]]

One option is missing: No, and I don't plan to!

Too bad they've ditched the MTASC project in favor to haXe...

[hangalot]

i am with Sx on this. haXe is a nice idea, but i would have loved for him to rather build a as3 compiler. once you have used flex builder 2 or fdt you also realise what a difference a proper editor makes, i know they are writing an eclipse plugin for haXe but its the same people who wrote asdt (fdt kicks that way out of the window)
some of my friends are very involved in haXe but i would rather spend my time learning sparkle than another language that compiles down to a flash 8 swf.

[FFighter]

It´s only a matter of time for great editors such as FlashDevelop to full support haXe. Maybe some commercial solutions too? (I don´t see why FDT team shouldn´t start working on haXe support!)


i would rather spend my time learning sparkle than another language that compiles down to a flash 8 swf.

haXe adds another level of abstraction above actionscript, so, you can actually have a project that compiles to flash 6, 7, 8 or for the new virtual machine too (Nicolas is working on that).

Cheers,

Marcelo.

[[Sx]]

It's only a matter of time when we'll start using C++ for DHTML scripting, VB for writing drivers and time crucial applications, XML for storing bitmap data, MS Windows on a toaster, JavaScript for cross-platform programming, ActionScript for shell scripting...

I just don't get it... why does people tend to take a perfectly good technology for what it does and - throw it away by spanning it to things that it's not meant for? Instead of improving existing technologies that are good at what they do, and strengthening the bounds between them, we just say - it's terrible how it's now done so let's make it our way in hope that it will become the best thing since the sliced bread... There are good backend solutions, there are good connectivity solutions and there are good frontend solutions, and now instead of everyone putting their best efforts to strengthen their fields, everyone wants to interfere on the other fields. That in turn leads that brain-power gets spilled across a wide area and none of the products end up to be perfect as you need to work on multiple fields... Same goes for MTASC - very good SWF compiler that could end up being perfect, but hell no - it's just not enough, let's make a backend for it, and protocols, and... And in the end haXe will end up just like any project that took a bite more than it could chew.

People just doesn't seem to learn lesions from others that tried the same thing and failed miserably... Take for example IBM - what it was 20 years ago, and what it is now... From invention-oriented company it turned into a mere computer dealer for other invention-oriented companies. Wanna more recent case? Apple... Because their focusing on iPod and similar gadgets, they've neglected the Macintosh platform which in turn leaded that they've had to switch to Intel platform, and now it's only a matter of time when they'll have to ditch the whole platform and turn into an OS supplier. And how long they can survive against Microsoft on that field? Don't be surprised in 5 years when people start saying: "Macintosh... hmmmm, sounds familiar... what was it?'.

It happens all around us just because people are too greedy (not necessarily in material way) - it would be much nicer world when everybody would do what they do the best and perfect it through full devotion to it... But you can't fight human nature I guess...

[Mortimer Jazz]

Nicolas is without doubt one very smart cookie, but i don't think the way the MTASC issue was handled towards the end was overly confidence-inspiring.

If I remember correctly (from one particularly long Flashcoders post) he estimated that it would only take him 2-3 weeks additional work to get MTASC compiling for AS3, but then made it clear he wasn't prepared to do that - there followed pleas and offers to pay him for that time, but he still said no. He's totally within his rights of course - for most, switching back to the MMCompiler wouldn't be a major issue, but some projects do depend more heavily on MTASC, and they didn't get the support they needed. He could just as easily drop all support for haXe in favour of Project #3 and that makes me wary.


@Hangalot - agreed FDT does indeed rock.

[[Sx]]

Well, good thing is that MTASC is open source (tho I really hate the OCaml layer) - so no one said that it can't be actually upgraded to support AS3 no matter if haXe will or will not have a bright future. But the problem is - finding someone (like me :p) with enough competence and time to actually make it (and maintain it in the future). Too bad it's under GPL and not BSD licence, as in the second case some company could actually invest in few competent people to make MTASC a really great compiler...

[Mortimer Jazz]

You're right, OCaml was indeed the main stumbling block. Those with the time and enthusiasm didn't have the knowledge, so (as far as I'm aware - I stopped follwoing the thread after a while) work stopped dead on MTASC with no real prior warning.

It just makes me a little more wary than usual.
I wouldn't want to become too relient on haXe, only for all work to cease without warning, at a time that may be critical to my project such as a release dadline.

I would be less wary if there had been a hand-over or phase-out period for MTASC, or if Nicolasse had agreed to remain involved in some other capacity.

[[Sx]]

I stopped following the MTASC development when it got around 1.10 version - at that state it was quite clear that it will eventually die, tho even when the rumors started that MTASC is getting it's successor haXe, I couldn't believe someone would ditch quite well refined compiler such was MTASC in favor to some new platform. I mean I even ditched my own AS compiler in favor to MTASC.

And that certainly has shaken people's confidence in the group that was working on it (mainly Nicolasse) - if they suddenly killed the MTASC with no real reason (i mean it was, and still is quite good at what it does) who can vouch that it wont happen with haXe? I mean it's ok for the enthusiastic people willing to try new stuff, but a large company would think twice before making their platform dependent on something that can disappear over the night - would you buy a touristic arrangement from non-official company located in some garage, and knowing that they've held similar company that disappeared over night and left their current users all over the world on their own?

In either case, it was quite irresponsible to ditch MTASC over-night. Don't know if Nicolasse realizes it - but with such sudden move he might have killed hundreds of other projects that were dependent on MTASC development. It certainly ruined my personal 'experiment' DynaLoad (successor to my xEngine) - a small platform for run-time Flash classes/packages management which I was hoping to evolve in quite useful platform with AS3. It was based on my own compiler till I discontinued working on it and ditched it in favor to MTASC which was quite frankly far better compiler. Spent countless of hours just to make the system working with MTASC, only to find out at the end that MTASC will never get AS3. So I would certainly have a big problem trusting the same group again. And not only that - I see no reason why would they go for backend solutions and 'protocol' solutions. I have perfectly layered backend and communication with Flash - the weak link is the compiler, and MTASC was a great thing for that purpose, so ditching it just for spreading the 'impact' area is quite illogical to me. I've already talked about that few posts back...

[ncannasse]

I've replied to concerns concerning haXe support on theses two emails :

#1 (http://osflash.org/pipermail/osflash_osflash.org/2006-May/008986.html) and #2 (http://osflash.org/pipermail/osflash_osflash.org/2006-May/008988.html)

Also, I would to say that MTASC is still supported ;) It's simply that it doesn't have a lot of bugs left ! And who would use MTASC3 when Adobe distributes freely an AS3 compiler working on all platforms ?

[FFighter]

I think it´s mostly a paradigm shift. haXe technology is indeed something very new and amazing, and we tend to refuse to take the time to analise it carefully and see its real benefits. Flash has been through many paradimg shifts until it reached the status of a platform. It started as a mere animation tool and has morphed into a complete development language. I just ask you to think more before making any assumptions about new technologies. The world is always changing and we just can´t have a closed-mind!

ncannasse: Nice to see you here Nicolas!

[jsebrech]

Now, let's be fair, compilers are special beasts. I doubt the learning curve would have been that much less steep had mtasc not used ocaml but something else. Even a competent C programmer will have difficulty understanding a lex/yacc based compiler written in C. What you need knowledge of is compiler design, not the particular tools and languages used to build the compiler.

Is ocaml really that hard to learn? It's just another language, right? That nobody has picked up the further development of mtasc to me demonstrates that nobody really truly needs that development to happen, or they would bite that bullet and learn about ocaml / compiler design.

I do agree that relying on haxe or mtasc for your income is a bad idea if you don't have the know-how to maintain it, or the funds to hire someone to maintain it for you. Doing that is a bankrupcy just waiting to happen.

[ncannasse]

I do agree that relying on haxe or mtasc for your income is a bad idea if you don't have the know-how to maintain it, or the funds to hire someone to maintain it for you. Doing that is a bankrupcy just waiting to happen.

I don't agree with that at all. It's called FUD, and I'm explaining why in that Post on OSFlash list Here (http://osflash.org/pipermail/osflash_osflash.org/2006-May/009043.html). To make it short : haXe (http://haxe.org) is supported by company, and will be continue to be supported in the following years. And to reassure you, we are very far from goind bankrupt or something of this kind.

[FFighter]

It is good to know your company has also switched to haXe Nicolas. Now I remember that you once said that you always used "MotionTypes" to build your flash applications and, correct me if I´m wrong, haXe is meant to be the MotionTypes successor, right?

I guess it would be nice if you could show the community some of your company´s work maybe?

Cheers,

Marcelo.

[jsebrech]

I don't agree with that at all. It's called FUD, and I'm explaining why in that Post on OSFlash list Here (http://osflash.org/pipermail/osflash_osflash.org/2006-May/009043.html). To make it short : haXe (http://haxe.org) is supported by company, and will be continue to be supported in the following years. And to reassure you, we are very far from goind bankrupt or something of this kind.

I may have exagerated when I used the bankrupcy word, but still, my point is not FUD, because it's based on practical experience. If you rely on code that you can't adapt (or pay someone to adapt) to suit your needs, then you're building a castle on sand. As I understand it, the further development of haxe will primarily be based on what your company needs, not on what the wider haxe community needs. That is an automatic risk in my book.

Having said that, after some thought, I would say that the risk with haxe is not larger than with other software products, since it has source available, so my apologies if I initially made it seem worse than it is.

[ncannasse]

If you rely on code that you can't adapt (or pay someone to adapt) to suit your needs, then you're building a castle on sand.

That works for Flash also : you can't adapt the Flash Player. Adobe might not develop the things you need in the future. If you apply your principle, you shouldn't use Flash then ?

haXe is Open Source, you can always hire someone to develop it the way you want/need. It's a general purpose programming language, not especialy designed for my company needs (some of our work available here (http://motion-twin.com/projects.html)). It's extensible through libraries and is very stable right now.

Having said that, after some thought, I would say that the risk with haxe is not larger than with other software products, since it has source available, so my apologies if I initially made it seem worse than it is.

Yes that's the way it is, I would say it's actually lower than using proprietary technology (you don't know when Adobe will come with AS4....), but there is great chances that haXe will support the future Flayer Player versions.