41–50 of 91 posts
I want to love Haxe but tooling outside of Windows seems limited, although I havent looked at how good VS Code is with it yet, so maybe I'll look into that. Otherwise I am going to stick to D and Python.
I want to love Haxe but tooling outside of Windows seems limited, although I havent looked at how good VS Code is with it yet, so maybe I'll look into that. Otherwise I am going to stick to D and Python.
Best way to learn it?
Then explore the code cookbook for more advance usage and patterns https://code.haxe.org/
Haxe is strange in that it seems to be very well known among developers but relatively very few actually use it. I guess it's an old project with very specific use cases; like building certain kinds of multi-platform apps. It's nice to see a project with such a dedicated community. It's a shame that most developers started using TypeScript instead of Haxe; that seems like a missed opportunity. TypeScript was pretty p…
I'd say one of the issues with Haxe was always tooling. I don't know how it is now, but when I was looking at it a few years ago, debugging it wasn't really possible.
[0] https://github.com/vshaxe/eval-debugger
[1] https://haxe.org/manual/debugging-source-map-javascript.html
Earlier quoted context omitted.
Counter-example: Dart. If corporate support is a definite factor, Dart would have taken off way earlier than now. A bigger factor in TypeScript's success would be the ability to gradually migrate the projects as it's a superset of JavaScript. How do you start migrating? Flip the file extensions from .js to .ts with loose compiler options, then gradually add typing as the options are tightened. It's factors like these…
Dart suffered from corporate politics, Chrome team wasn't really into it, got rescued by Ad Words team, and now are trying to become relevant outside Google with help Flutter. If Chrome team actually cared about Dart and went ahead with Dartium's integration, Dart's future would have been much different. Then the Angular team decided to dump Dart and go with Typescript. So politics as usual.
And in addition to not having full support from Google, there was not and probably would never have been buy-in from Mozilla or Microsoft. Also the language IMHO didn't offer much more than JavaScript, and 6to5 -> Babel was gaining traction at the same time. It wasn't a good recipe for success.
I first learned about Haxe through Lucas Pope’s dev log for “Papers, Please”. Sounded interesting and fun, though Pope (who developed PP on a Mac) said he also had written custom tooling for his work — maybe that situation had changed since 2014: https://www.gamasutra.com/view/news/209905/Road_to_the_IGF_L... For his new game, Return of the Obra Dinn, he went with Unity because of its 3D capability: https://forums.ti…
Earlier quoted context omitted.
What was bad specifically? This comment reads more of a ‘the codebase we inherited sucked to rewrite’ than anything else.
Some things are generic critiques of haxe: standard library has poor documentation and big feature gaps, often important third party tools are basically abandoned, no support, generated code is extremely hard to debug or understand (both C++ and Javascript outputs for us). Conditional compilation is a horrible, horrible idea period, and is particularly easy to turn into an indecipherable brittle mess in haxe. This wa…
I will agree to your point about abandoned third party tools but that happens with any language? It’s just more pronounced on a less popular one. I will also agree about the code it produces: the point of a transpiled language isn’t for its output to necessarily be readable but first and foremost fast. You wouldnt expect c to produce understandable assembly in all cases, would you? Plus it maps all lines to your Haxe source so you shouldn’t even have to debug large blocks of native code anyway.
What necessarily does Haxe do that makes for conditional compilation to be so bad? AFAIK it works in the exact same way other cross platform frameworks have it (eg, Unity)- it’s probably the cleanest way to do it; I certainly wouldn’t say it promotes brittle code practices at all, but ofc, like anything, can be misused.
I can see it being a potential turnoff to candidates given it’s relatively unknown status... but the language itself reads and writes like a C-style OOP language: there’s nothing that should necessarily turn people off besides that it’s an unknown, especially anyone coming from a C or Java background.
I used haxe a lot in the past, but with the newer enhancements to JavaScript I found that I ended up using JavaScript. Destructuring assignment arrow functions and more concise object literals, ... operator enable much more concise and readable code. Haxe seems to be much more conservative in development. Haze is aquiring arrow functions but I think there was quite a degree of initial resistance to the notion. I prop…
As for the process, I think it has become a little more stringent for sure. To submit a request for consideration you’d need to submit a proposal on GitHub with attention paid to impact to existing code and impact on future Haxe features- perhaps your feature request wasn’t deemed to be thought out enough? It also looks like you’d get more explicit consideration if you are a sponsor of the language (https://haxe.org/foundation/support-plans.html)
So yes, while it isn’t a completely open vote, I also think most languages’ directions are decided by committee in a similar way. I’m sure the Haxe community would love to see examples of other communities with better practices to learn from.
I used haxe a lot in the past, but with the newer enhancements to JavaScript I found that I ended up using JavaScript. Destructuring assignment arrow functions and more concise object literals, ... operator enable much more concise and readable code. Haxe seems to be much more conservative in development. Haze is aquiring arrow functions but I think there was quite a degree of initial resistance to the notion. I prop…
Change proposals are subjective, so people can have different opinions on whether a change should be accepted or whether it was well-formulated enough. What bugs me though is that the Haxe team has a documented process for considering and voting on these proposals, which they don't follow. If Nicolas doesn't like a feature, it's essentially vetoed. If he changes his mind later, it'll be implemented without any further discussion. Most discussion happens in an internal Slack channel so there's no transparency. It's essentially a BDFL masquerading as a democracy, and it can be frustrating to try to contribute as an outsider if you don't realize that. See inline XML for example (https://github.com/HaxeFoundation/haxe-evolution/pull/26) - a lot of discussion, open questions remaining, seemed like Nicolas was generally resistant. Then suddenly, there's a PR and it's merged, and it will be in the next version of Haxe.
IMO, this is not the way to run an open source project. And in my experience, the team is resistant to feedback and takes things personally, so I've lost confidence that it will change.
Earlier quoted context omitted.
Some things are generic critiques of haxe: standard library has poor documentation and big feature gaps, often important third party tools are basically abandoned, no support, generated code is extremely hard to debug or understand (both C++ and Javascript outputs for us). Conditional compilation is a horrible, horrible idea period, and is particularly easy to turn into an indecipherable brittle mess in haxe. This wa…
I’d love to hear more. What’s missing from the std features? Where are the docs lacking? I will agree to your point about abandoned third party tools but that happens with any language? It’s just more pronounced on a less popular one. I will also agree about the code it produces: the point of a transpiled language isn’t for its output to necessarily be readable but first and foremost fast. You wouldnt expect c to pro…
I would like to argue about this philosophy. When your target output is not readable, then you restrict the developer to work inside your upper-level language. This is fine if your upper layer is robust and transparent enough to reason about. In C's case, there is rarely a case one needs to work at the assembly level to reason/debug. Is this the case for Haxe? Now if you even imply that developer need work in your output layer even one percent of the time, then it is responsible to make sure the output is readable. Otherwise, it is a gun shooting the foot -- even only 1% of the time.
The background is that I love C. I find C very straightforward to reason about and very simplistic to allow more logic to be spelled out in a clean way (than C++ for example). Now the above passage -- putting assembly as an analogy to C -- sounds prickly.