HaXe - Code Once. Deploy Everywhere.
haxe.org
haxe.org
Ignoring, for a moment, the complexity of deploying software across multiple platforms, it's important to remember the multiple form-factor problem. The same software doesn't work from a user's standpoint on multiple platforms if the UI isn't correct for that device. The best example I can give is "mobile versions" of sites and apps, clearly targeted at the form factor of a phone, being delivered to a 10" tablet. It's crappy.
Bring in the obvious elephant in the room of the number of times this claim has been made from an engineering standpoint and truly failed to deliver, and I yawn every time HaXe is mentioned.
JavaScript has almost solved this problem, if one views HTML and CSS as the domain-specific languages which JavaScript deploys for rendering its GUIs. You have to know a lot of quirks, but when you finish a site which looks nice in Firefox you can have a reasonable assurance that it doesn't look absolutely horrible in WebKit browsers.
What's more surprising is that it has come this close to solving that problem, but I don't remember anyone ever promising JavaScript as something of this nature. There exists some JavaScript pride today, especially with CoffeeScript and Node.js, but since at least my first internship in the summer of 1999 it has been faced with inconsistency and standardization pains -- and I don't remember anyone before that time promising that you could run the same HTML/CSS/JS everywhere. By those standards it's more of a 15-year goal than an initial pitch.
Yes, you have to make allowances for the actual differences between platforms (physical buttons, screen sizes, input methods), but the rest of the code deploys extremely well across platforms. When moving between platforms, you only have to rewrite the pieces that you actually want to be different.
A truly harder cross-platform problem is to abstract access to OS GUI in usable way.
In the case of HaXe, its focus has emerged from Web games with server-side needs, where UI is primarily a concern on only one platform, or shared between two platforms(Flash and JS/HTML).
Although there are now several haXe libraries that are willing to suffer the "slings and arrows" necessary to provide a flexible API experience, the core language is very realistic about what it is going to provide across all platforms - a limited set of data, logic, and networking compatibility. In all other respects the language is very, very concerned with being able to drill down to the native features of each platform and achieve as native an experience as possible given the constraints of a garbage-collecting, dynamic/static mixed, classy OO language design.
I have to say though, I've been using NME (haxenme.org), which uses the haXe language. It really does work, and it performs significantly faster than Adobe AIR or Corona.
I would not use it to make a website UI, that is for HTML / CSS.
I do use it for games. I do use it for server side programming. I do use it for complex Javascript (including games).
It's write once, deploy smartly. Of course I can't write a server side program and then have it run on my phone, that doesn't even make sense!
I use haXe on a daily basis, for cross-platform application development and for me: => 1 platform (soft or hard) = 1 app.
But haXe makes it possible to keep the application logic, and not to start from scratch every time.
And I publish for a lot of platforms, in web and native forms: mobiles, smart TVs, tablets, html5 websites with a Flash version used as a fallback in case one do not have a recent browser, points of sell / touch screens. And some haxers target the game consoles.
So it is really impressive, even if the slogan is clearly not true nor relevant - haXe community has always have problems with communication (last time I talked about it with one of the founders, he answered "what communication problems? it is the most efficient way to communicate", and I finally understood that he was talking about client-server communication :D no comment!
It has some very nice points, but "code once, deploy everywhere" is ridiculous. So many of the crucial APIs are platform dependent that there is absolutely no way your HaXe application is going to be portable.
However, the NME project (http://code.google.com/p/nekonme/) is getting pretty good; it emulates the Flash APIs on other platforms. Great for games; probably not usable for the kinds of stuff you do at Justin.tv.
I don't do contract or consulting work, so you don't have to worry about me trying to sell you something. :)
* The Haxe C++ output is very solid. Sometimes there are compiler errors that you have to reverse engineer, like for when you use a try{} without a catch{}, which is valid in Haxe, but throws an error in C++. It's relatively easy though; the C++ output contains which haxe file and line number each line is from, and it has never taken more than a minute or two to figure out what's going on.
There has only been one logic error I've experienced - Haxe guarantees that arugments of a function are called left to right (i.e. something( readbyte(), readbyte() );), but of course C++ does not. Other than that, as far as the core compiler and code generation goes, if it compiles, the generated code is sound.
* Use NekoNME - bootstrapping on the iPhone without it would require a whole bunch of work. It is an API compatibility layer with Flash, and most basic stuff is replicated. So you code against the Flash APIs, and it spits out a native app on the iPhone, etc. That said, call as few of the Flash APIs as possible; roll stuff by hand, because they kind of suck.
* The garbage collector is quite slow, especially on the iPhone. So you have to be careful about the number of objects you've got in flight, even/especially strings. I don't keep Black Market's story in memory even on the PC version of the game because of this.
* The C++ generated code is very very fast. Though of course some optimisations aren't possible, like creating vectors on the stack, so for example the Haxe Box2d port is slower than the original C++ version of Box2D (I had to use pooled Vectors in Super Goblin).
* If you're making something using 2D graphics, catering to the myriad of display resolutions is going to suck. But that's not a function of Haxe.
* Similarly, you end up doing a whole bunch of work per platform anyway; stuff like putting in app purchasing into the iPhone apps required (at least when I did it) hacking it into the native sections of the NME libraries (a pain, but doable).
* Checkout NME once, and stop updating when it's working well - it breaks often, and is in constant development.
* That said, if you're a hacker, get commit access to NekoNME. If you commit solid changes back they'll love the extra help, and you're likely to want to add some missing features (not as many these days as there were when I did it a year ago).
Now that Unity3D supports Flash, my next game is actually going to be written in that (see http://www.underthegarden.com). However, if Haxe fits your needs (eg write your website backend, Javascript, SWF, iPhone app, PC downloadable all from the same codebase), it's solid and will likely be around for a long time; there'll be some teething pain, but it isn't a lemon technology wise.
The reason I suggested people email me is so I can help figure out if it actually does fit their use case!
I remember at one point being part of the crowd that laughed at "Write once, run anywhere" slogan that Sun used for Java ("Write once, debug everywhere" was the joke back then). If you look at how things stand today, however, it has become mostly true (for server side applications).
If it "might eventually become true," they might want to reword how declarative the saying is, or change it to something like "Code once. Deploy everywhere. Maybe someday."
It is a really fantastic language for many different platforms and I definitely recommend checking it out.
2. as2 is a superset of javascript, so it also has inline functions.
3. Having worked in haxe quite a bit, I found that the fancy type system got in the way more than it helped. I can't think of one case where it caught a bug, but I do have memories of spending hours writing typedefs and casting things to Dynamic.
4. You can't really target multiple platforms in practice, because nearly everything you might want to do depends on host-specific features. A multi platform codebase would be riddled with "if (flash) { } else if (c++) { } else if (javascript) { ...".
2. It (AS2 & JS) has functions as a first class type that you can define anywhere, but it does not have inline functions in the commonly accepted C/C++ sense of the definition. Actual inline function support as included in haxe can be hugely important on devices with underpowered CPUs since making a function call has significant overhead in ActionScript when you are running on a dinky ARMv5 core. With inline functions there is no function call thus no overhead (at the cost of making the 'compiled' code larger, which is often a perfectly fine tradeoff).
3. I love the type system, so again I guess this is subjective.
4. There is some truth to this but it is easy to encapsulate code that has to be platform aware (generally UI stuff) into libraries and then keep your primary app code platform independent.
[1] http://en.wikipedia.org/wiki/JavaScript#Functional [2] http://en.wikipedia.org/wiki/Inline_function
I recently wrote a haXe version of "Pirate Pig", a sample game originally written for Enyo in JavaScript. It took me about a day of work to write, and it went straight to webOS, Android, Windows, Linux, Linux 64-bit, Flash, Mac and the iOS simulator.
It would have gone to an actual iOS device, too, but I was too lazy to pull out my iPod Touch.
If you are interested, please feel free to view the game online, in the webOS App Catalog, Android Market or downloadable. All the source code and assets are available, too:
http://www.joshuagranick.com/blog/2012/02/22/nme-game-exampl...
I am very thankful for haXe, which makes the NME project possible. The great part is that it really works.
This is a multiplatform API for 2D games. It runs as native Dalvik code on Android with a GL backend. On the Web, it runs as JS using GWT for compilation, and either a Canvas or a WebGL backend. For flash, it uses the http://code.google.com/p/gwt-flash addon for the GWT compiler to produce SWFs. For iOS, it uses iKVM to run Java bytecode on Monotouch. I believe the same code can also run on the XBox and perhaps Windows phone. Box2D is builtin.
See http://www.youtube.com/watch?v=VtwUyu7UzcM for http://www.youtube.com/watch?v=F_sbusEUz5w for a longer presentation I did at Google I/O.
Music had 7 symbols and they have perfect interoperability, Software has 2 symbols and interoperability is a dream.
0110100101100110001000000111100101101111011101010010000001100011011000010110111000100000011101000111001001100001011011100111001101101100011000010111010001100101001000000111010001101000011010010111001100100000011101110110100101110100011010000110111101110101011101000010000001101100011011110110111101101011011010010110111001100111001000000110100101110100001000000111010101110000001011000010000001110100011010000110010101101110001000000110100100100111011011000110110000100000011000100110010101101100011010010110010101110110011001010010000001111001011011110111010100100000011010110110111001101111011101110010000001110111011010000110000101110100001000000111100101101111011101010010011101110010011001010010000001110100011000010110110001101011011010010110111001100111001000000110000101100010011011110111010101110100
My only criticism would be the 32bit integer handling in the neko target. I'm not sure if its changed recently, but the last time i used it i had to wrap all operations in "Int32.<operation>(<int32 object>)" function calls which to me was a completely braindead solution.
In other words, I wouldn't get my hopes up :/
If I start learning this language , I am not sure if I am actually getting the full benefit of what a Java/Python provides. I am not convinced until I actually see a production ready solution.
wow, that claim makes me feel old. i've lost track of how many existing/legacy ways we have to write once, deploy anywhere, multi-platform apps. it's like what they say about the great thing about universal ultimate standards: there are so many to choose from!
Kernighan, Richie, UNIX and C.
Or to take more lighthearted - If there really was promise, there would've not been need for a preprocessor.
Or the API docs?
Or maybe you rather reading a book?
http://www.amazon.com/Professional-haXe-Neko-Programmer/dp/0...
http://www.amazon.com/haXe-Beginners-Guide-Benjamin-Dasnois/...
It's great that you invented a new programming language. haXe is very cool. But why do you feel the need to disparage other programming languages?
If you personally don't like dynamic typing, that's fine. But putting that in the blurb for haXe will annoy a large potential audience for your language. For what?
I didn't take it as a disparaging of dynamic typing.
But why the singling out of JavaScript? The statement is true for Python, Ruby and Lua as well.
And why even mention another language or class of language in a negative way? I propose that the sentence would better have been written as
> haXe has a very strict compile-time type checking feature that allows you to catch errors before testing your program in the browser
It loses nothing by removing the disparaging part.
As a person who likes (the good parts of) JavaScript, I read it as trying to appeal to me with promises of less debug time.
It started out as an actionscript (which is javascript) compiler for flash that was simply enerated far faster swf files than the macromedia toolchain.
From this grew an actionscript like language called haxe that strives to solve what were seen as the wrongs of the javascript language. And in my opinion it succeeds.
Its cool to see that the cross platform angle grows and i hope haxe reaches the mainstream awareness it deserves.
You should try it :)