6 ms·

I think the value of Haxe comes from being able to use one language across platforms, not anything specific to the language itself. Could you speak to the spec

I think the value of Haxe comes from being able to use one language across platforms, not anything specific to the language itself. Could you speak to the specific "warts" you found while using it? I'm genuinely curious.

benologist 12y ago
My favorite is Array.sort. Since it's consistent with many other languages you won't get to the docs until your app is crashing. Instead of being fixed it's had a recommended alternative buried in the docs for I think years: 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. Every platform has its own gaps in the API. This is evident in this submission - after the author translated his JavaScript he then had to fix his haxe to work within the subset available to C#. 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.
- RussianCow 12y ago
  I see. Are there a lot of these warts? To be fair, if all the inconsistencies are documented, that seems like a fairly minor inconvenience for the benefits you get. (I don't know how well-documented they actually are, so maybe the answer is "not".) 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.
  - benologist 12y ago
    The success story mentions the dev had to learn OCaml to fix bugs in Haxe, other comments here by jdk and reallyRaoul refer to inconveniences too. Elsassph mentions some of the issues are specific to OpenFL not haxe, that's true both ways. I think you can reasonably expect to encounter issues. Do you expect to encounter any bugs at all - outside your own code - in Java, Objective C etc when you do your native UIs?
    - jonasmalaco 12y ago
      I don't do that many UIs at all, so I wouldn't know about that. Even so... 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.
    - RussianCow 12y ago
      > Do you expect to encounter any bugs at all - outside your own code - in Java, Objective C etc when you do your native UIs? 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.
    - ousado 12y ago
      Of course you have to learn the language the compiler is implemented in when you're hacking the compiler. That's not an inconvenience, it's a tautology.
  - jonasmalaco 12y ago
    I've known Haxe for almost 7 years and have been using it extensively in the past 4. 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).
- djur 12y ago
  Could you explain what's wrong with Array.sort? Lots of languages' standard libraries have unstable sorts, including C. What kind of crashes could be caused by an unstable sort?
- rfrey 12y ago
  This is a strange complaint. Quicksort isn't stable in most implementations either. The docs are exactly where I'd look to see if a particular sort method was stable... where else? I really don't mean to be condescending, but are you interpreting "stable" to mean "crash free"?
  - deleted 12y ago
    [deleted]
  - benologist 12y ago
    I don't think it is reasonable to blame me for encountering a bug in their code, the problem is in their code. Please read the success story - the person advocating for it describes plenty of time spent compensating for it for reasons much more diverse than this one example. This is a common experience - mentioned in several comments here too.
    - jonasmalaco 12y ago
      Well, it simply isn't a bug. Most sort algorithms aren't stable, and the only thing a generic _sort_ algorithm is supposed to guarantee is a sorted output according to the comparison function you supply it with. If however the method was called "stableSort", the situation would be very different... 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.
      - benologist 12y ago
        It is not important we agree on this being a bug or not. If you have had a smooth experience you don't have to look further than the linked success story to find a counter-example.
- ousado 12y ago
  You make it sound like you actually experienced crashes due to an unstable sort function in Haxe. 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.
  - benologist 12y ago
    In our case on Android Array.sort throws exceptions. Pretend I nominated something the success story developer had to learn some OCaml to fix in the Haxe compiler instead, it is just an example and doesn't change the common narrative.
    - jonasmalaco 12y ago
      Please report that bug. The core team (or other devs familiar with Haxe like myself) will be happy to fix it. 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.

benologist 12y ago

My favorite is Array.sort. Since it's consistent with many other languages you won't get to the docs until your app is crashing. Instead of being fixed it's had a recommended alternative buried in the docs for I think years: 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. Every platform has its own gaps in the API. This is evident in this submission - after the author translated his JavaScript he then had to fix his haxe to work within the subset available to C#. 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.

RussianCow 12y ago
I see. Are there a lot of these warts? To be fair, if all the inconsistencies are documented, that seems like a fairly minor inconvenience for the benefits you get. (I don't know how well-documented they actually are, so maybe the answer is "not".) 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.
- benologist 12y ago
  The success story mentions the dev had to learn OCaml to fix bugs in Haxe, other comments here by jdk and reallyRaoul refer to inconveniences too. Elsassph mentions some of the issues are specific to OpenFL not haxe, that's true both ways. I think you can reasonably expect to encounter issues. Do you expect to encounter any bugs at all - outside your own code - in Java, Objective C etc when you do your native UIs?
  - jonasmalaco 12y ago
    I don't do that many UIs at all, so I wouldn't know about that. Even so... 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.
  - RussianCow 12y ago
    > Do you expect to encounter any bugs at all - outside your own code - in Java, Objective C etc when you do your native UIs? 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.
  - ousado 12y ago
    Of course you have to learn the language the compiler is implemented in when you're hacking the compiler. That's not an inconvenience, it's a tautology.
- jonasmalaco 12y ago
  I've known Haxe for almost 7 years and have been using it extensively in the past 4. 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).
djur 12y ago
Could you explain what's wrong with Array.sort? Lots of languages' standard libraries have unstable sorts, including C. What kind of crashes could be caused by an unstable sort?
rfrey 12y ago
This is a strange complaint. Quicksort isn't stable in most implementations either. The docs are exactly where I'd look to see if a particular sort method was stable... where else? I really don't mean to be condescending, but are you interpreting "stable" to mean "crash free"?
- deleted 12y ago
  [deleted]
- benologist 12y ago
  I don't think it is reasonable to blame me for encountering a bug in their code, the problem is in their code. Please read the success story - the person advocating for it describes plenty of time spent compensating for it for reasons much more diverse than this one example. This is a common experience - mentioned in several comments here too.
  - jonasmalaco 12y ago
    Well, it simply isn't a bug. Most sort algorithms aren't stable, and the only thing a generic _sort_ algorithm is supposed to guarantee is a sorted output according to the comparison function you supply it with. If however the method was called "stableSort", the situation would be very different... 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.
    - benologist 12y ago
      It is not important we agree on this being a bug or not. If you have had a smooth experience you don't have to look further than the linked success story to find a counter-example.
ousado 12y ago
You make it sound like you actually experienced crashes due to an unstable sort function in Haxe. 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.
- benologist 12y ago
  In our case on Android Array.sort throws exceptions. Pretend I nominated something the success story developer had to learn some OCaml to fix in the Haxe compiler instead, it is just an example and doesn't change the common narrative.
  - jonasmalaco 12y ago
    Please report that bug. The core team (or other devs familiar with Haxe like myself) will be happy to fix it. 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.