It looks interesting to say the least, I like the concept and intent at least. However, it seems to me that it’s so muddied that it won’t perform too well due to the fact that for most languages you’re going between at least two optimizers and compilers. I suppose you could make a lot of similar arguments for programming in any language that’s not assembly, but this one seems especially prone to that problem since it piggybacks on so many other languages.
I may give it a try, but I was wondering what the general consensus on this language is (if, indeed, there is one).
It looks interesting but I have to wonder how well it maps onto those different languages.
It seems like the intended advantage of something like this would be that you’d only have to learn one language for many different platforms and uses, but I’m skeptical that it would work out like that.
It seems like you would have to have some knowledge of the target language and tailor your HaXe code to it.
I doubt that you could write your HaXe code without thinking about the target language and then be able to compile it to any or all of those languages. If I’m correct then what is the advantage?
That’s my concern too, to a degree. I think that it definitely CAN generate compilable code with roughly the same function as the HaXe code in any supported language, but I have incredible doubts that it won’t be completely wonky and inefficient compared in many cases. It’s definitely something you won’t be writing big applications in if you can help it.
Looks to me like the newest iteration of a platform-free language that will work on anything. There’s always a few of those out there. The problem with 'em is that so far, nobody’s come up with anything that really works for complex programming projects that isn’t a pain in the ass and ends up making you write native code anyway, so there’s no advantage.
Don’t get me wrong - it’d be cool if someone could figure something like this out - but it’s not a simple problem. If it were, we wouldn’t be stuck in this world of C# versus Java versus Objective-C versus C versus C++ versus Javascript versus SQL etc. etc. There’s a reason each of those still exist (even if it’s not a good reason) and I don’t see us all gravitating towards a single language for a long, long time.
Well, it makes me feel good that my opinion matches that of current researchers, since I haven’t been exposed to programming language theory since college in the 80s.
I thought I might chime in here, since I use haxe for a few projects. Overall, I would give haxe more credit than “the few of those out there” that try to handle more than one target.
First of all, not all haXe targets are equal. Some targets are more polished than others. For instance, the haxe language is much more powerful for creating high performance swf code. It also has many more features for the swf target than adobe’s own compiler does. In general, haXe can perform extremely well when it generates bytecode. Other languages that target the JVM (scala, clojure, etc.) are now very well respected languages, even though they target a “foreign” runtime.
HaXe also targets scripted languages, such as javascript and php. There are many more issues with these. Since the runtime relies on dynamic typing, you don’t get any of the usual speed/efficiency benefits from haXe’s statically typed code. Script runtimes can also use idiosyncratic rules that break or change types in some cases. For instance, the haxe php target overflows integers to doubles without warning. This causes issues with any math operations that rely on overloading. Even with these issues, haXe can still be useful. For instance, the haXe compiler generates scripted code that follows a consistent “pseudo” namespace. This enables you to not have to worry about accidentally overloading global variables and methods in php or javascript. It also allows you to generate or compile larger javascript/php libraries without worrying about name clashes between two different libraries. HaXe has redundant code removal, and numerous other optimizations for these targets as well.
Two new targets for haxe (.net and jvm) should be available by the end of the summer. I’d encourage folks to keep an eye open for the announcement, and give it a shot if either of those targets are relevant. That should bring the total number of targets to 8 (swf8, swf9, js, php, c++, neko, jvm, .net)
Each target uses the native vm/runtime garbage collector. The sole exception is the C++ target, which uses Boehm since garbage collection is not built in for the language.
