I looked around in the front page and also docs on haxe.org, but didn’t see an answer to this. I also checked the readme in the Haxe Evolution repo, but nothing there. Same with the Haxe Evolution Process blog post.
What are the core values/philosophy/goals that guide development of the Haxe language? To what language design tenets do the core Haxe devs adhere?
What I see so far (after briefly poking around):
cross-platform
fast compilation
familiar syntax
access to each platform’s native capabilities
What else though? (For example, in Haxe which is more important, expressiveness or readability? Simplicity or convenience? More runtime checks or faster performance? Breaking changes (fix things!) or long-term backcompat?)
For runtime check vs performance it seems to be the latter, several part of the API are target defined or have edge cases unspecified to keep reasonable speed.
No idea if haxe wants to be expressive or readable.
I do find it readable and its syntax is certainly inspired by popular languages, nothing too out of the ordinary there. There will ofc be some things unknown, but a C#/Java/AS3 developer could understand most of it.
Thank you for the reply and the links as well, Valentin!
Glad to hear that Haxe has a focus on simplicity and is conservative about adding syntax. I think this is one on the main things that has helped, for example, Python so much.
Grateful also to hear that breaking changes happen when needed. I’ve seen debates in various language communities on both sides (for example, in D (dlang)), and it seems to come down to the vision of the core team / project lead.
Regarding performance, I recall that Clojure for example does not seem to do much in the way of helping you avoid runtime errors — if you pass garbage in you may (or may not!) get garbage out (though this may be changing with clojure.spec), but it’s good for performance. After a quick look at Lua, my guess is that it may be similar in that regard (ex., undefined → nil, extra function args ignored, etc). Due to Haxe’s static typing, and that it’s compiled, I’m sure it catches many programming errors at compile time. That sounds lovely. Thanks again for the provided links.
Regarding expressive/readable, maybe my question wasn’t very good. I understand expressive to mean that the language provides enough features to allow easy expression of intent — but too many features and you end up with everything but the kitchen sink in there (readable for experts, but difficult to master). So, for example, Perl is very expressive, but at a cost of having lots of operators and syntax. Python is less expressive, a little more verbose, but is a much simpler language, which IMO is a win. You’ve said that Haxe leans toward simplicity, and I see so far that it favors easily-readable names for things rather than ascii-art operators. So, maybe Haxe is expressive and simple, but also can be slightly more verbose than some other languages? If so, I think that’s an excellent combination: provide what’s needed to be expressive, but you’ll have to type more words (verbose) to get that. Is that right?
Thinking about it again it might lean toward expressiveness, that’s something you kind of forget after a while but haxe has a lot of features that might make it hard to read code using those as a beginner.
Thanks, Valentin. I suppose the language designer must often wrestle with making the language expressive while also keeping it readable.
Great talk by Jeff Ward! Thank you for the link. From his “WTH” moments, I can see how function types can get a little longish, but can made more readable with use of typedefs.
Will watch some more videos. BTW, the video section at haxe.org is really handy, and well-organized!
Hi Kevin. Thanks for the reply. Oh, boy, this is opening a can of worms. Maybe this should be a blog post — well, maybe I’ll turn it into one once I know Haxe better.
Yes, I’m new to Haxe. I’ve been using Python for scripting, ETL tasks, and web stuff. But lately I’ve been experimenting with other languages, looking for something comparable to Python but which offers more help from the tooling in spotting errors early. I also wanted to get more into creating desktop and/or webapps, and the current job market seems heavily slanted toward JS webapps for this.
I don’t have any experience with AS3, and not much interest in writing games.
I don’t know Haxe well at all yet, but it’s interesting to me for these reasons:
So far it appears to be superior to compararable popular languages (Java, JS).
From what I can tell, Haxe is not tied to compatibility with (or otherwise beholden to) any particular underlying target language/platform. For example, TypeScript and JS, or Clojure and Java/JVM.
It’s statically-typed, and so, I suspect, will help me find my errors sooner than with Python or JS. I’ve gotten the impression that in general the Haxe compiler is very good at helping one find one’s mistakes.
It’s unashamedly GC’d. I’m disinclined to manually manage memory (or ownership/lifetimes, as in Rust) for the types of work I’d like to do.
Haxe uses (and I like) bog-standard C/Java/JS -style syntax (though I realize this is just personal preference and familiarity).
Like some other languages, supports the option of compiling to JS (for webapps), but also can compile to native for desktop apps. And I’m very excited about HashLink as well (for scripting or desktop apps)!
So far seems to have very fast compilation. And, for some targets, very short app startup time.
Appears to be quite a practical language. I noticed in the Debian package description it’s called, “multi-target universal programming language” which sounds eminently practical.
Ability to access native C-libraries.
Again, I don’t know it well enough yet, but it appears to have less magic or syntactic sugar than some of its contemporaries. For example, I had a look at Kotlin, but as I recall Kotlin supported some syntactic shortcuts (reminiscent of Ruby) that I wasn’t happy with.
I have the impression that Haxe is a community-driven project. It’s also great to see the presence of the Haxe Foundation. And Haxe’s license is GPL-compatible.
Incidentally, when I first ran across Haxe years ago, I’d somehow gotten the impression that Haxe was an MSWindows-specific (or, at least -centric) language/toolkit, and so I’d discounted it. Glad to find that it’s multi-platform and that it works fine for me on GNU/Linux so far.
(Yow. That’s a long list above. Maybe I’m too picky. Please let me know if I’m off-base on any of my suppositions above!)
Anyhow, I mostly began this thread because, regarding the core Haxe design team goals, I wanted to know:
Does it break backcompat when necessary? (This sounds like a “yes”, at least going from v2→3, and 3→4.) (This would be unlike languages which slavishly maintain bug-for-bug backcompat forever and ever, in perpetuity, and just keep getting larger and more complicated with each release.)
Is simplicity and elegance a goal? Because languages for which those are goals are the languages I most enjoy using. (This sounds like a “yes” as well.)
Is Haxe good at helping me catch my mistakes? Because I need all the help I can get.
), API docs, and the code cookbook