7 ms·

Haxe 2.10 - Now with Java and C# targets

99 points by stesch 14y ago

Ralith 14y ago
Why not JVM and CLR targets?
- deleted 14y ago
  [deleted]
  - Ralith 14y ago
    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 14y ago
      [deleted]
- chipsy 14y ago
  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.
  - jdonaldson 14y ago
    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.
    - georgemcbay 14y ago
      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).
      - jdonaldson 14y ago
        You're right, it was as2. I should've mentioned this was true "at the time"
  - Ralith 14y ago
    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.
    - jdonaldson 14y ago
      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.
      - Ralith 14y ago
        > 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++?
        benatkin 14y ago
        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.
danboarder 14y ago
Will updating haxenme update the version of haxe I am running? Or should haxe be updated separately? Thanks.
- novalis 14y ago
  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.
  - singmajesty 14y ago
    Yes, actually ;) We're about a half hour away from NME 3.4
Rickasaurus 14y ago
Haxe is interesting only because of its targets. No advanced type features at all.
- mahmud 14y ago
  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.
  - jdonaldson 14y ago
    Nicolas "Cannasse" just left his company, I'm not sure what he's up to next. It should be interesting to see.
    - sspiff 14y ago
      Where did you hear/read this?
      - nickmain 14y ago
        http://ncannasse.fr/blog/time_for_new_adventures http://ncannasse.fr/blog/time_for_new_adventures
- stewbrew 14y ago
  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.
  - joneil 14y ago
    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.
zupatol 14y ago
Cross-platform tools often have a single user interface that tends to look foreign on every platform (sencha touch), or they force you to code a different ui for every targeted platform (titanium?). How is the ui problem is usually tackled with haxe? I tried googling a bit, but didn't come up with a conclusive answer.
- joneil 14y ago
  The short answer is that Haxe isn't very good here yet. Many of the companies using Haxe are game studios, and so they just invent their own UI and it doesn't matter if it doesn't feel "native". In terms of the two approaches you mentioned: both can be used. There are various projects to "reinvent" a basic UI toolkit that works on NME, the cross platform graphics layer. These libraries would do what you mentioned first - have a consistent experience across platforms, but one that is foreign and probably not as polished. No libraries have really gained a huge amount of support for this yet, though it seems there are a few trying. The other approach - integrating with native UI - is also possible using Externs, which link in with an underlying system. I'm not sure how much use this has had. Some iOS features have externs, and on the desktop wxWidgets externs are around so this approach is possible. If you were to do this I guess you'd try to abstract away as many differences as you can, so that you need as little conditional compilation as possible. Not sure who is trying this at the moment. As I said though, UI toolkits is definitely not a strong point. My main development with Haxe is for JS / HTML, so I just use standard bootstrap / jQuery elements, which feel "web native" I suppose.
  - wiradikusuma 14y ago
    then why dont you use plain html/js instead? skip extra 'translation' step.
- giulianob 14y ago
  As someone else mentioned, Haxe is mainly used for games where the UI is always custom anyways. There are frameworks like ASwing which work with Haxe to give a very flexible UI but it's not a native look and feel.
- 14y ago
fijal 14y ago
The documentation looks absolutely horrible. I can find in many ways how it can compile to multiple targets, but no easy way to find out how it actually looks like. Any "hello world" example that does not contain language reference? Maybe "a gentle introduction to haxe" before "compiler metadata"?
- vanni 14y ago
  http://haxe.org/doc/snip http://haxe.org/doc/snip http://haxe.org/doc/snip/hello http://haxe.org/doc/snip/hello
  - fijal 14y ago
    I didn't say it does not contain a hello world example. However it really misses (or at least misses in some obvious place, like the first link) "a gentle introduction to haxe". For example if you go to python.org -> documentation -> there is a clear link "tutorial" with subtitle "start here". Hell, even php has a relatively easy to find "tutorial" as a first part of docs. You guys should really reorganize this in a bit more friendly way, especially that haxe is not (at least yet) an incredibly popular language with tons of tutorials all over the net.

99 points by stesch 14y ago

Ralith 14y ago

Why not JVM and CLR targets?

deleted 14y ago
[deleted]
- Ralith 14y ago
  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 14y ago
    [deleted]
chipsy 14y ago
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.
- jdonaldson 14y ago
  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.
  - georgemcbay 14y ago
    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).
    - jdonaldson 14y ago
      You're right, it was as2. I should've mentioned this was true "at the time"
- Ralith 14y ago
  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.
  - jdonaldson 14y ago
    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.
    - Ralith 14y ago
      > 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++?
      - benatkin 14y ago
        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.

danboarder 14y ago

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

novalis 14y ago
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.
- singmajesty 14y ago
  Yes, actually ;) We're about a half hour away from NME 3.4

Rickasaurus 14y ago

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

mahmud 14y ago
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.
- jdonaldson 14y ago
  Nicolas "Cannasse" just left his company, I'm not sure what he's up to next. It should be interesting to see.
  - sspiff 14y ago
    Where did you hear/read this?
    - nickmain 14y ago
      http://ncannasse.fr/blog/time_for_new_adventures http://ncannasse.fr/blog/time_for_new_adventures
stewbrew 14y ago
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.
- joneil 14y ago
  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.

zupatol 14y ago

Cross-platform tools often have a single user interface that tends to look foreign on every platform (sencha touch), or they force you to code a different ui for every targeted platform (titanium?). How is the ui problem is usually tackled with haxe? I tried googling a bit, but didn't come up with a conclusive answer.

joneil 14y ago
The short answer is that Haxe isn't very good here yet. Many of the companies using Haxe are game studios, and so they just invent their own UI and it doesn't matter if it doesn't feel "native". In terms of the two approaches you mentioned: both can be used. There are various projects to "reinvent" a basic UI toolkit that works on NME, the cross platform graphics layer. These libraries would do what you mentioned first - have a consistent experience across platforms, but one that is foreign and probably not as polished. No libraries have really gained a huge amount of support for this yet, though it seems there are a few trying. The other approach - integrating with native UI - is also possible using Externs, which link in with an underlying system. I'm not sure how much use this has had. Some iOS features have externs, and on the desktop wxWidgets externs are around so this approach is possible. If you were to do this I guess you'd try to abstract away as many differences as you can, so that you need as little conditional compilation as possible. Not sure who is trying this at the moment. As I said though, UI toolkits is definitely not a strong point. My main development with Haxe is for JS / HTML, so I just use standard bootstrap / jQuery elements, which feel "web native" I suppose.
- wiradikusuma 14y ago
  then why dont you use plain html/js instead? skip extra 'translation' step.
giulianob 14y ago
As someone else mentioned, Haxe is mainly used for games where the UI is always custom anyways. There are frameworks like ASwing which work with Haxe to give a very flexible UI but it's not a native look and feel.
14y ago

fijal 14y ago

The documentation looks absolutely horrible. I can find in many ways how it can compile to multiple targets, but no easy way to find out how it actually looks like. Any "hello world" example that does not contain language reference? Maybe "a gentle introduction to haxe" before "compiler metadata"?

vanni 14y ago
http://haxe.org/doc/snip http://haxe.org/doc/snip http://haxe.org/doc/snip/hello http://haxe.org/doc/snip/hello
- fijal 14y ago
  I didn't say it does not contain a hello world example. However it really misses (or at least misses in some obvious place, like the first link) "a gentle introduction to haxe". For example if you go to python.org -> documentation -> there is a clear link "tutorial" with subtitle "start here". Hell, even php has a relatively easy to find "tutorial" as a first part of docs. You guys should really reorganize this in a bit more friendly way, especially that haxe is not (at least yet) an incredibly popular language with tons of tutorials all over the net.