A success story for Haxe
nadako.tumblr.com
nadako.tumblr.com
(at least it was for me...I was amazed at how fast Pope built and ported a cross-platform game considering he's a one-man shop...though to be fair, he was also able to learn Flash and build games for Ludum Dare competitions...so he's probably an outlier :) )
Another interesting thing to look at is the OCaml source for the Haxe compiler itself. https://github.com/HaxeFoundation/haxe
At first, I was hesitant to do much with the compiler since I don't know OCaml. But, I recently forked the source and am making an attempt at a lua target: https://github.com/jdonaldson/haxe/tree/haxe_lua_rb1
It's been a great way to learn OCaml, and Lua. If you're interested in creating your own Haxe target, I'm hoping my commit log will be helpful.
https://itunes.apple.com/us/app/world-zombination/id68062469...
Great looking game and near perfection on gameplay, idea, brand, art, assets, ui, icon etc. Flawless victory.
Here's a port of the jQuery TodoMVC for anyone wanting a quick example of what a web-target would look like. https://github.com/explorigin/todomvc-haxe
Besides that, the type system of Haxe is far more expressive than those of most languages that also compile to JS. Ocaml, Scala and Haskell are the better known languages that are actual competitors in that regard.
I'm unfamiliar with Ocaml, Scala and Haskell but OK.
I like the idea of this approach way more than the one that projects like Xamarin take (build a common runtime on top of each platform) because you don't incur any runtime overhead, and debugging would (in theory) be much easier because you can just debug the native language instead of needing to understand the extra VM layer on top. As a bonus, with Haxe you can also target the web, which you can't do with Xamarin/RoboVM/RubyMotion/etc.
Has anyone tried anything like this (not necessarily with Haxe) and had success with it?
[0]: https://github.com/ralcr/swift-target
Edit: Wording and clarification, added bit about targeting web.
If you're just looking for multi-platform stuff, that's almost a minimum requirement now: unity3d, unreal engine, xamarin, javascript etc.
Haxe has the ability to integrate much more cleanly across all of these platforms imho.
Could you speak to the specific "warts" you found while using it? I'm genuinely curious.
The sort operation is not guaranteed to be stable, which
means that the order of equal elements may not be retained.
For a stable Array sorting algorithm,
haxe.ds.ArraySort.sort() can be used instead.
OpenFL isn't a mature platform and their releases are rushed and buggy. If you download and install <older OpenFL> their setup process will install the newest version of dependencies and their incomplete documentation will leave you to figure out what versions are actually compatible. Gestures are a pain in the ass with immature and incomplete libraries.
The one thing that makes it worth using - barely - is the decade and a half of ActionScript experience I also have.
Also, if I were to use Haxe for mobile development, it wouldn't be through OpenFL; I would use the native APIs of each system and just write a thin wrapper in Haxe that's common for all platforms. I just want to reuse code, not adopt a completely separate UI toolkit.
Do you expect to encounter any bugs at all - outside your own code - in Java, Objective C etc when you do your native UIs?
These languages are certainly more mature than Haxe, but I do still expect to find some bugs in their standard libraries (in performance or security).
And when you factor in third-party libraries, the answer is always "yes you do expect to encounter bugs" independent of the language. For me, programming is in great part reading and fixing other people's code, and I still think most of them are much more skilled than me.
No, but I'd wager that I would spend more time re-writing the app for each native language than I would finding the inconsistencies in Haxe. (And either way, each platform has its own nuances that you have to know whether or not you use Haxe.) For the record, you'd have the same issues with solutions like Xamarin. The whole thing is a trade-off, and I have a (well-supported) hypothesis that the benefits of a (semi-)shared codebase is worth the cost of learning these nuances and inconsistencies.
In my experience, inconsistencies between targets and undefined behaviour were common, but most cases have since been removed or documented.
Also, I find it's usually trivial to see how a given Haxe API (be it one in the standard Haxe library or from a third-party lib) maps to native calls.
Personally, the fact everything in the Haxe ecosystem is open-source and has reasonable scale (for instance, the std API by design isn't as big as Java's) is one of the reasons I like it so much. Even though I can't code in Ocaml and modify the compiler itself, I feel that can I solve most time-sensitive issues that might arise (bugs, unexpected behaviour, extending APIs, etc.).
Other reasons I code a lot in Haxe are: code reuse; powerful type system (ADTs, abstracts...); macros; reasonably pleasant syntax (although a bit verbose for my taste).
I really don't mean to be condescending, but are you interpreting "stable" to mean "crash free"?
The default Array.sort stability is inconsistent across targets _because_ guaranteeing it would prevent reusing implementations already available in the targets. And differently than what you claimed, many languages (and most Haxe targets) don't guarantee sort stability in their default "sort" APIs: C, C++, C#, JS, PHP and Neko.
Also, any remark placed in the official api docs for "Array" or in that very module, just next to sort method, can't be said to be "buried" in the docs.
I'm not dismissing the existence of a bug just because of this (although the issue may be related to it), but non-deterministic comparison functions are problematic with many sort _algorithms_. You might experience (other) problems when using implementation independent "sort" APIs, since many algorithms need to rerun the comparison function several times and expect consistent behaviour; I would expect certain algorithms to, for instance, never complete.
You even make it sound like that was a common occurrence due to a deliberate decision on part of the development team to not fix that alleged source of crashes, but rather refer to an alternative in the documentation.
You should clarify that you haven't made this experience, and that no one you know or have heard of ever has.
You seem to have no idea how unlikely it is that the various Array.sort implementations (they're usually provided by the respective target platforms, of course) all have some bug that leads to crashes, moreover, you seem to be unaware that most target platforms provide such basic APIs, which in turn shows how little you know about Haxe.
As the documentation already explains, "unstable" in the context of a sort function is about the order of elements that are equal from the perspective of the comparison function. That's basic CS terminology. It's not about crashes, and it's not about bugs in Haxe or the respective target platforms.
You simply misunderstood, but you keep insisting. Which sheds some light on the overall quality of your comments about Haxe here.
Also, consider that 65% of the code in the haxe git repository is written in Haxe, not OCaml. There's a lot you can change, extend or fix without knowing OCaml at all.
Other uses for Haxe are the JavaScript target which a number of companies are using extensively in the same way you would be using typescript/coffeescript.
I think the focus is going to be on generating objective c, rather than swift. Although, that's the entire extent of my understanding.
This is pretty much the approach that Google use with Inbox, except they used j2objc instead of RoboVM.
class Test {
static function main() {
var people = [
"Elizabeth" => "Programming",
"Joel" => "Design"
];
for (name in people.keys()) {
var job = people[name];
trace('$name does $job for a living!');
}
}
}The "people" instance is using anonymous syntax for a Map type. Haxe's Map types are actually abstract types: http://haxe.org/manual/types-abstract.html. I doubt many developers are familiar with this type of feature.
For instance, here's a "packed array" implementation that lets me store an array of integers in a fraction of the space usually needed for a standard array type: https://github.com/jdonaldson/packhx Abstract types let me use the same api that standard arrays use (including array accessors), even if the underlying runtime implementation is completely different.
The other nice things going on in the example is the simple for loop using an iterator, and the nice string interpolation. Granted, this is nothing super sophisticated, but it's great to have these same features across all the targets that Haxe supports.
If you have an example of a better code sample for introducing language syntax, I'd love to see it so I can learn from it.
for ((name, job) in people) {
trace('$name does $job for a living!');
}My problem with it is that it seems to have gone somewhat stale. It's been almost a year since the last update, and at least for the JS target, a number of the great external libraries never made the hop over to the 3.0 codebase.
You make a great point; just because a project doesn't put out updates once a week doesn't mean it's stale. There are some other great projects like haproxy and redis that are clean enough and stable enough that regular updates aren't necessary.
I guess you sort of grow accustomed to that mentality when dealing with some other common OSS projects
You should try the nightly builds or compiling straight from Git. They are stable enough for many purposes (and if you report a bug chances are that its fix will soon be available) and you can take advantage of new features.
By the way, there's a new release planned for the next weeks.
What does shared code mean in this context? Can someone give an example?