Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Haxe 2.10 - Now with Java and C# targets

haxe.org

Post reply on HN
Print view View original

11–20 of 44 posts

Re: Haxe 2.10 - Now with Java and C# targets

#11

Post by Ralith »

jdonaldson wrote: post #10
Ralith wrote: post #9

Earlier quoted context omitted.

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.

> Once again, there's nothing wrong with jvm output. It's "better" for the reasons you say.

So if my understanding, including that bytecode generation requires a comparable amount of effort, why didn't they do that? I don't intend to critique their decisions; I'm interested in why they made them. Their reasoning might well teach me something.

> providing source code in java/c++ is critical for ... various mobile app stores.

Really? I wasn't aware of that. Are we talking Apple's and Google's? What app store's catalog is predominately C++?

Re: Haxe 2.10 - Now with Java and C# targets

#12

Post by chipsy »

Ralith wrote: post #9
chipsy wrote: post #6

Earlier 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…

VMs can have bugs and nuances that aren't captured in their specification - and a compiler has to evolve awareness of this in an iterative fashion. Rendering to source languages constitutes another way to sanity check by going through a compiler that has already dealt with those implementation concerns. So Haxe is taking on a lot of extra work, as you say, but it also gains more assurances that output is "as good as" target-native code.

Re: Haxe 2.10 - Now with Java and C# targets

#13

Post by Ralith »

chipsy wrote: post #12
Ralith wrote: post #9

Earlier quoted context omitted.

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…

VMs can have bugs and nuances that aren't captured in their specification - and a compiler has to evolve awareness of this in an iterative fashion. Rendering to source languages constitutes another way to sanity check by going through a compiler that has already dealt with those implementation concerns. So Haxe is taking on a lot of extra work, as you say, but it also gains more assurances that output is "as good as"…

> VMs can have bugs and nuances that aren't captured in their specification

So can compilers. Adding the additional translation layer of javac or equivalent increases the potential of being affected by bugs in third-party code. Let P be the probability of encountering a bug in the JVM, and Q be the probability of encountering a bug in javac. If we multiply the complements, (1-Q)x(1-P) we have the probability of final execution being in keeping with the HaXe implementation's intentions. Assuming all values are nonzero, (1-P)x(1-Q) > output is "as good as" target-native code.

But it isn't. Translating code between languages is lossy. Unless HaXe is trivial, the HaXe implementation has information that could be used to generate better bytecode that is lost when bytecode generation is performed by a tool that knows nothing about HaXe, e.g. javac.

Re: Haxe 2.10 - Now with Java and C# targets

#14

Post by benatkin »

Ralith wrote: post #11
jdonaldson wrote: post #10

Earlier quoted context omitted.

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.

> Once again, there's nothing wrong with jvm output. It's "better" for the reasons you say. So if my understanding, including that bytecode generation requires a comparable amount of effort, why didn't they do that? I don't intend to critique their decisions; I'm interested in why they made them. Their reasoning might well teach me something. > providing source code in java/c++ is critical for ... various mobile app…

Why should it be predominately C++, in order to have an easy time being reviewed?

There's plenty of C++ code in the iOS App Store. I know a couple of people who've developed most of the code for their iOS apps in Visual Studio. They were computer vision apps with just a little bit of GUI toolkit code.

Re: Haxe 2.10 - Now with Java and C# targets

#15

Post by novalis »

danboarder wrote: post #4

Will updating haxenme update the version of haxe I am running? Or should haxe be updated separately? Thanks.

If you are already on NME 3.3.3 (latest release), no. It comes with Haxe 2.09. But I am guessing it will not be long before another NME release and it will probably come with Haxe 2.10. Don't know if something would brake if you updated to 2.10 per Haxe installer but am not going to find out. Joshua is probably working at it as we type.

Re: Haxe 2.10 - Now with Java and C# targets

#16

Post by georgemcbay »

jdonaldson wrote: post #7
chipsy wrote: post #6

Earlier 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…

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.

mtasc was an AS2 compiler, not an AS3 one.

As of Flex3 (~2008) Adobe's AS3 compiler has been open source.

(But haxe is still better than AS3, IMO).

Re: Haxe 2.10 - Now with Java and C# targets

#17

Post by bodyfour »

Ralith wrote: post #9
chipsy wrote: post #6

Earlier 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…

> it's my understanding that producing bytecode is as easy as--if not vastly easier than--producing code in another language

Maybe true for unoptimized code. However, Java and C# compilers have received years of work to make efficient use of their respective VMs; standing on their shoulders makes some sense.

Re: Haxe 2.10 - Now with Java and C# targets

#19

Post by jdonaldson »

georgemcbay wrote: post #16
jdonaldson wrote: post #7

Earlier quoted context omitted.

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.

mtasc was an AS2 compiler, not an AS3 one. As of Flex3 (~2008) Adobe's AS3 compiler has been open source. (But haxe is still better than AS3, IMO).

You're right, it was as2. I should've mentioned this was true "at the time"

Re: Haxe 2.10 - Now with Java and C# targets

#20

Post by singmajesty »

novalis wrote: post #15
danboarder wrote: post #4

Will updating haxenme update the version of haxe I am running? Or should haxe be updated separately? Thanks.

If you are already on NME 3.3.3 (latest release), no. It comes with Haxe 2.09. But I am guessing it will not be long before another NME release and it will probably come with Haxe 2.10. Don't know if something would brake if you updated to 2.10 per Haxe installer but am not going to find out. Joshua is probably working at it as we type.

Yes, actually ;)

We're about a half hour away from NME 3.4

Post reply on HN