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

21–30 of 44 posts

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

#21

Post by MichaelGG »

bodyfour wrote: post #17
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…

> 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.

Really? What kind of optimizations does the C# compiler do when emitting IL? As far as I know, they are fairly straightfoward optimizations - there's nothing really that complex going on there. The C# team has said they aim for a straightfoward mapping to IL.

You won't see the C# compiler inlining functions (even though the CLR does _way_ better with large functions and doesn't handle inlining well). It won't propagate constant expressions. You won't see it transforming recursive functions into loops. Does it even remove unused variables?

All the optimizations that C# really relies on for performance are handled by the JIT, and any compiler following the same patterns will get the same enhancements, plus the ability to emit better IL than C#.

That said, I'm still unconvinced it's easier to emit MSIL than C#, and I'm rather well versed with MSIL.

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

#22

Post by chipsy »

Ralith wrote: post #13
chipsy wrote: post #12

Earlier quoted context omitted.

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…

> Adding the additional translation layer increases the potential of bugs

> the implementation has information that could be used to generate better bytecode

These are theoreticals. Let me analogize. Some algorithms have a worst-case big O that is significantly worse than the average case. So even though the algorithm could have very poor performance in certain situations, it's better for the "real-world" cases that it gets used in.

Most of the existing Haxe targets have similar external semantics(Algol-derived, GC, dynamic types), so we're in an average-case situation of both reliability and performance; the Q probability is close to zero because the code we input isn't that drastically different from human source input, and the input we pass in from Haxe can be a bit more optimized in most respects, because we don't have to make it maintainable. If we were targeting a really bad compiler, it would blow up. But in practice, it doesn't and we gain more than we lose, even when considering areas where there's an impedance mismatch and we have to, for example, add dynamic types on top.

Bytecode output is more sensible within a short-term view - a single project with known specifications. But it's ultimately the need for flexibility that drives Haxe, and you aren't gaining additional flexibility from bytecode.

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

#23

Post by jdonaldson »

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…

> So if my understanding, including that bytecode generation requires a comparable amount of effort, why didn't they do that?

They might. It's just not what they've chosen to do first.

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

Well, we're talking the iOS app store here. Objective C is the main language, but Apple also supports c++ xcode projects, which Haxe can produce. The reason why Haxe targets c++ is because it can provide garbage collection through the Boehm libs, and (in general) can be made to fit better with the Ecmascript nature of the Haxe language.

Google is much less restrictive in terms of supported languages, but their java toolkit is very polished.

I also think that source code generation also lets you understand better what the compiler is doing, and how to best take advantage of it. Right now, the java target is very early, but it already has a clever way of handling reflection that is much faster than the standard method. It was interesting to me to read through the generated output, even if it was a little ugly.

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

#24

Post by mahmud »

Rickasaurus wrote: post #18

Haxe is interesting only because of its targets. No advanced type features at all.

Or advanced anything else for that matter.

Cannese is a really bright programmer though; man built a programming language with an interesting runtime, and manages to use them for his one-man game studio. Not bad.

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

#25

Post by jdonaldson »

mahmud wrote: post #24
Rickasaurus wrote: post #18

Haxe is interesting only because of its targets. No advanced type features at all.

Or advanced anything else for that matter. Cannese is a really bright programmer though; man built a programming language with an interesting runtime, and manages to use them for his one-man game studio. Not bad.

Nicolas "Cannasse" just left his company, I'm not sure what he's up to next. It should be interesting to see.

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

#26

Post by malkia »

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…

Source to source solves the problem where the only way to ship for certain platform is to compile only with the toolchain provided.

The Unity3D engine for example uses Mono's AOT (C#) to produce a very big assembly file (.S) which later goes through apple's own (or is it gnu's) as (assembler).

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

#27

Post by stewbrew »

Rickasaurus wrote: post #18

Haxe is interesting only because of its targets. No advanced type features at all.

Why does a language have to have advanced whatever features if it does the job, i.e. if it's good enough to write most of a cross-platform app in a maintainable manner while producing efficient code?

Note: I am not a haxe user and would be interested in comments of actual users with respect to the compiler's reliability. My personal conception is that it is quite difficult to define a stable language that defines exactly the same on all targets.

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

#28

Post by joneil »

Rickasaurus wrote: post #18

Haxe is interesting only because of its targets. No advanced type features at all.

What sort of advanced features are you hoping for?

Genuinely interested, I use Haxe and find it's type system advanced enough for me - but maybe there's awesome features in other languages that I don't know about yet.

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

#29

Post by joneil »

stewbrew wrote: post #27
Rickasaurus wrote: post #18

Haxe is interesting only because of its targets. No advanced type features at all.

Why does a language have to have advanced whatever features if it does the job, i.e. if it's good enough to write most of a cross-platform app in a maintainable manner while producing efficient code? Note: I am not a haxe user and would be interested in comments of actual users with respect to the compiler's reliability. My personal conception is that it is quite difficult to define a stable language that defines exa…

I'm a haxe user. What exactly are you wanting to know?

If by reliability you are talking about it consistently not breaking between versions, then it's fine. Between versions the compiler does add new features but for the most part backwards compatibility has been kept between major versions.

If you're talking about does it consistently produce similar code across platforms, then it depends. Plenty of people are using it for 2D games (targetting flash, Android and iOS) and it seems suitable for this. Outside of that, it basically comes down to this: if you want your code to work cross platform, stick to the standard library or to known cross-platform libraries.

As an example, I had a piece of code which took markdown text input, converted it to HTML, and then manipulated the resulting HTML. The code worked on Javascript, Neko and CPP without modifications, because I stuck to existing cross platform libraries.

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

#30

Post by jdonaldson »

stewbrew wrote: post #27
Rickasaurus wrote: post #18

Haxe is interesting only because of its targets. No advanced type features at all.

Why does a language have to have advanced whatever features if it does the job, i.e. if it's good enough to write most of a cross-platform app in a maintainable manner while producing efficient code? Note: I am not a haxe user and would be interested in comments of actual users with respect to the compiler's reliability. My personal conception is that it is quite difficult to define a stable language that defines exa…

I think Haxe is unique in the balance it is trying to find between compilation speed, platform consistency/reach, and advanced language features. My personal observation is that Nicolas and the other language authors seem to prioritize things as I've just listed them.

Compilation speed thing is a "big deal" that I don't hear talked about a lot on HN. Haxe's compiler is so fast that it provides autocompletions by itself. So, completing fields from "using" mixins, constructor inference, structural types, or macro generated methods are all very fast, and guaranteed to be correct. So, perhaps while Haxe's features are not as robust as a few other languages, they feel much more tightly integrated with most coding workflows.

Post reply on HN