
Haxe 2.10 - Now with Java and C# targets - stesch
http://haxe.org/doc/release/2.10
======
fijal
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
<http://haxe.org/doc/snip>

<http://haxe.org/doc/snip/hello>

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

------
Ralith
Why not JVM and CLR targets?

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

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

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

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

------
zupatol
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
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
then why dont you use plain html/js instead? skip extra 'translation' step.

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

~~~
novalis
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
Yes, actually ;)

We're about a half hour away from NME 3.4

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

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

