Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A success story for Haxe

nadako.tumblr.com

Post reply on HN
Print view View original

51–60 of 67 posts

Re: A success story for Haxe

#51

Post by ousado »

explorigin wrote: post #2

I'm in the process of learning Haxe. I hope it becomes more popular since you can have macros, static type-checking and a shared code-base with one language. You can have all these things with Javascript but not at the same time (that I know of). 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

When you write Javascript, do you mean TypeScript, AtScript, something else? There's no type checking in JS, and there is no metaprogramming support in JS, let alone of the quality it can be found in 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.

Re: A success story for Haxe

#52

Post by ousado »

benologist wrote: post #13
RussianCow wrote: post #8

Earlier quoted context omitted.

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.

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 ins…

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.

Re: A success story for Haxe

#53

Post by jonasmalaco »

benologist wrote: post #50
rfrey wrote: post #43

Earlier quoted context omitted.

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"?

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.

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.

Re: A success story for Haxe

#54

Post by k_roy »

ousado wrote: post #47
k_roy wrote: post #45

We recently adopted it to provide a sane base to our Javascript. Personally, I LOVE it. It's cleaned up our code so much. 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.

Development hasn't stalled at all, neither for the JS target nor for most other targets. The core compiler is being improved constantly, which benefits all targets, and there have been improvements in the JS code generator, too (which isn't easy, the code quality has been very high, already).

Oh I definitely have nothing bad to say about Haxe. I was mostly just referring about some of the external libraries that never made the jump over from legacy, which could be indicative of developers jumping ship.

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

Re: A success story for Haxe

#55

Post by jonasmalaco »

k_roy wrote: post #54
ousado wrote: post #47

Earlier quoted context omitted.

Development hasn't stalled at all, neither for the JS target nor for most other targets. The core compiler is being improved constantly, which benefits all targets, and there have been improvements in the JS code generator, too (which isn't easy, the code quality has been very high, already).

Oh I definitely have nothing bad to say about Haxe. I was mostly just referring about some of the external libraries that never made the jump over from legacy, which could be indicative of developers jumping ship. 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…

Development has been quite stable: https://github.com/HaxeFoundation/haxe/graphs/contributors

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.

Re: A success story for Haxe

#56

Post by benologist »

jonasmalaco wrote: post #53
benologist wrote: post #50

Earlier quoted context omitted.

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.

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 implemen…

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.

Re: A success story for Haxe

#57

Post by benologist »

ousado wrote: post #52
benologist wrote: post #13

Earlier quoted context omitted.

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 ins…

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…

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.

Re: A success story for Haxe

#58

Post by jonasmalaco »

benologist wrote: post #57
ousado wrote: post #52

Earlier quoted context omitted.

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…

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.

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.

Re: A success story for Haxe

#59

Post by jonasmalaco »

benologist wrote: post #56
jonasmalaco wrote: post #53

Earlier quoted context omitted.

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 implemen…

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.

Respectfully, it is important to understand whether sort stability is as bug or not. Particularly since you seem to have experienced exceptions on Android, and assuming that the problem was in the sort stability may have mislead you.

Re: A success story for Haxe

#60

Post by benologist »

jonasmalaco wrote: post #59
benologist wrote: post #56

Earlier quoted context omitted.

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.

Respectfully, it is important to understand whether sort stability is as bug or not. Particularly since you seem to have experienced exceptions on Android, and assuming that the problem was in the sort stability may have mislead you.

It's still reproducible just by substituting the top function for the stable alternative we use: http://pastebin.com/D3S6SYBM. Haxe 3.1.3 on OSX.
Post reply on HN