Haxe 2.10 - Now with Java and C# targets
1–10 of 44 posts
Re: Haxe 2.10 - Now with Java and C# targets
#2Why not JVM and CLR targets?
Re: Haxe 2.10 - Now with Java and C# targets
#3Why not JVM and CLR targets?
[deleted]
Re: Haxe 2.10 - Now with Java and C# targets
#4Will updating haxenme update the version of haxe I am running? Or should haxe be updated separately? Thanks.
Re: Haxe 2.10 - Now with Java and C# targets
#5Why not JVM and CLR targets?
[deleted]
I am not unfamiliar with HaXe. The only reason I can imagine for the authors having done this is that they did not know better. I am inclined to give them more credit than that, however, so I posted a question in the hopes that somebody else might have insight.
Re: Haxe 2.10 - Now with Java and C# targets
#6Why not JVM and CLR targets?
Most Haxe targets are source-to-source, with the exception of SWF. It bootstraps on existing toolchains a bit better(this can make a big difference for debugging), and it affords more flexibility in the build process in those situations where you really need to mix in code native to the target. The extra step of compilation to reach the runtime is treated as a UI issue. NME, for example, already has its own build system in order to deal with asset packaging, and it integrates the cpp target compilation alongside that.
This doesn't preclude the possibility of bytecode, but from the Haxe perspective it's seen as an optimization, not a must-have for practical use.
Re: Haxe 2.10 - Now with Java and C# targets
#7Why not JVM and CLR targets?
Most Haxe targets are source-to-source, with the exception of SWF. It bootstraps on existing toolchains a bit better(this can make a big difference for debugging), and it affords more flexibility in the build process in those situations where you really need to mix in code native to the target. The extra step of compilation to reach the runtime is treated as a UI issue. NME, for example, already has its own build sys…
I think this is mostly correct. Afaik, the swf (instead of as3) target was provided because the standard compiler (flash) was closed source. Nicolas Canasse, the Haxe language author, wrote an open source as3 compiler called mtasc, and then used his experience to make an optimized compiler for Haxe to swf.
Re: Haxe 2.10 - Now with Java and C# targets
#8Earlier quoted context omitted.
[deleted]
I am not unfamiliar with HaXe. The only reason I can imagine for the authors having done this is that they did not know better. I am inclined to give them more credit than that, however, so I posted a question in the hopes that somebody else might have insight.
[deleted]
Re: Haxe 2.10 - Now with Java and C# targets
#9Why not JVM and CLR targets?
Most Haxe targets are source-to-source, with the exception of SWF. It bootstraps on existing toolchains a bit better(this can make a big difference for debugging), and it affords more flexibility in the build process in those situations where you really need to mix in code native to the target. The extra step of compilation to reach the runtime is treated as a UI issue. NME, for example, already has its own build sys…
As a student of compilers myself, it's my understanding that producing bytecode is as easy as--if not vastly easier than--producing code in another language, and that this is particularly true when the target language is high-level. The only exception to this I can envision is when the source language maps easily and completely to every single target language, in which case the source language must be the least common denominator, and the compiler may be a glorified awk script.
Significantly, a major feature of the JVM and CLR bytecodes is that targeting them makes it extremely easy to permit interoperation with other code native to the same VM. I'm not sure generating source would be any improvement on this whatsoever. I also question the value of being able to debug generated code; assuming that HaXe is indeed more than a glorified awk script, the process might be compared to using an assembly debugger on C++-generated code. Not entirely useless, certainly, but neither is it precisely desirable.
Re: Haxe 2.10 - Now with Java and C# targets
#10Earlier quoted context omitted.
Most Haxe targets are source-to-source, with the exception of SWF. It bootstraps on existing toolchains a bit better(this can make a big difference for debugging), and it affords more flexibility in the build process in those situations where you really need to mix in code native to the target. The extra step of compilation to reach the runtime is treated as a UI issue. NME, for example, already has its own build sys…
As a student of compilers myself, it's my understanding that producing bytecode is as easy as--if not vastly easier than--producing code in another language, and that this is particularly true when the target language is high-level. The only exception to this I can envision is when the source language maps easily and completely to every single target language, in which case the source language must be the least commo…
Once again, there's nothing wrong with jvm output. It's "better" for the reasons you say. And, there may be a jvm target down the road.
That said, there's a number of situations where providing source code in java/c++ is critical for non-technical reasons... Say, if you want to get your project accepted in one of the various mobile app stores.