User talk:Wonderfl/Haxe

To the Haxe community,

Firstly, welcome to Wikipedia! Sorry about the bitter struggle that you all have faced on the haxe article, while it may not be your first, with a little bit of understanding, and a little bit of compromise (because not everything goes, here on Wikipedia), it can be your last.

I'm glad someone like TentorDa took the effort to understand my POV and why I was behaving in what appeared to be an erratic, unlawful and "troll-like" manner. (that's what you called me, right?!) Contrary to what you believe, I haven't really understood Haxe, although I spent hours browsing your website desperately trying to understand a system that was (IMO) quite sparsely documented (compared to C# or PHP or Java, it is). I have been working intensively with the Flash platform for the last 7 years and have therefore understood a lot about it, the FP internals, ABC, Alchemy, Types, etc.

Seeing the general perception of Wikipedia and the general misunderstanding with the way the system works, I was thinking of a kind of exchange offer. I teach you Wikipedia, and you teach me Haxe. That way everyone understands everything and suddenly no one's a "troll" or "idiot" anymore. But then I realized that it isn't just you that's "uninformed" about the complicated and twisted way Wikipedia functions. Its possibly a lot more people out there who are. So I'm going to start a series of talk pages (not real articles), where I'll give you an "insider's" look into Wikipedia, what it is, and why we, the few remaining contributors are the way we are.

Sorry for all the past, accept my apology regarding anything you have faced from other Wikipedians, or me, but Wikipedia has a few basic rules, and unless you can abide by those, honestly, you cannot publish the content you want to.

Please watch this section for guides on Wikipedia, written specifically for people like you. No, I don't think you're an idiot, but I just want to show you how this system works so you can succeed and improve the topics you want to. Start with this one that I just wrote.

In exchange, I'm going to post specific questions on this page. Please answer as many of them as possible, just below the question. I'll keep asking questions as needed. Once I understand how Haxe works, I'll champion for it on Wikipedia. But in general I need to understand it, and Wikipedia needs some proof. (proof = citations, even if you have it published on the Haxe website and link to that URL, its fine)

Have fun and thanks for working together. -- Tom Jenkins ^(reply) 04:43, 17 February 2013 (UTC)

Haxe/Cpp

Does haxe support every feature that C++ programs need? I've just barely touched C++ so not exactly my area of expertise.

Well, they are both high-level languages and offer similar concepts. C++, as an extension of C, allows one to go as low-level as one wants or needs. Haxe doesn't allow you to manipulate data at random memory locations, so you cannot do flexible memory manipulations in the way you can with C/C++. However, you can easily code a simple extension library to perform these operations as well. Beyond that, everything achievable with C++ is achievable in Haxe.

Can you use all the standard lib functions? What if the Haxe wrapper for a certain function/class does not exist, how do you access it then? Would it still be strongly typed?

Haxe wraps some things through its standard library (see the cpp package in the API docs). You can also access the C++ standard library directly, but you'd lose the strong typing. Still, everything is accessible one way or another.

Are there any drawbacks? Like inefficient code generation by the Haxe compiler or extra code added or anything that's worse than hand-written C++ code?

The Haxe compiler automates the code generation and thus does not achieve the quality of manually written C++ code. This results in a reduced execution speed, but it's felt only in really performance critical applications. The quality of the generated code is adequate though and modern C++ compilers would optimize it further. Overall, the generated code is quite usable for practical applications.

Does it support using/linking to 3rd party DLLs? or SO files? or 3rd party C/C++ code? How? Does it support using 3rd party C/C++ libs? How?

I've merged these 2 questions, because they are essentially the same. The short answer is: yes. There long answer.... to use a C++ library through Haxe you need to write some wrapper code using Haxe's CFFI. The reasons for this are that Haxe is a garbage collected language while C++ is not. This creates an incompatibility. Also, passing types from Haxe to C++ and back requires wrappers. So the practically relevant answer is: yes, but with an additional CFFI wrapper.

What about Windows/Mac/Unix support, do you support the full platform API here as well? Or a way to access it either ways? Is it strongly typed? What about iPhone/Android/WebOS support, do you support the full platform API here as well? Or a way to access it either ways? Is it strongly typed?

See the answer to the 2nd and previous questions.

Do you use the same generic types like Number and Int and Haxe converts it automatically to the relavent C++ type? Or must you use the full C++ type syntax like "unsigned short"

When coding for the C++ target you are still coding Haxe. This implies you are using the standard Haxe types. The numeric types in Haxe are Int and Float. They get converted to C++ types. So you don't have to know about "int / unsigned short / long / ..." to use integers.

Haxe/JS

Does haxe support every feature that HTML/JS programs need? Arrays? Objects? Prototypes? Closures? the JS Regex style? WebSockets? Can a full JS/AJAX website be built with haxe with no limitations?

The cheap answer is that if all else fails, you can always fallback to using __js__(any javascript code).

• Array: core type in haxe: http://code.google.com/p/haxe/source/browse/trunk/std/js/_std/Array.hx
• Object: haxe has full support for anonymous structures, which I assume is what you refer to
• Prototype: the haxe type system has no notion of prototypes, but they can still be used for javascript-specific code: untyped Array.prototype.indexOf
• Closures: supported
• Regex: supported through ~/regex/flags syntax, or via new EReg("regex", "flags")
• Websockets: available as a library: http://lib.haxe.org/p/WebSocket
• Ajax website: no problem at all

Does it support all the basic string, date, number functions? JS DOM/Browser API?. What if the Haxe wrapper for a certain function/class does not exist, how do you access it then? Would it still be strongly typed?

In some cases the haxe API may only provide a subset of the Javascript API specification. For instance, the String class in haxe has no match(regex) function, because you do regex.match(string) instead. Other classes like Date are streamlined to the most important functions, but it's easy to access them in a not type-safe way. It also requires only slightly more effort to write custom extensions and make it completely type-safe.

Are there any drawbacks? Like inefficient code generation by the Haxe compiler or extra code added or anything that's worse than hand-written JS code?

The generated code may be inferior to hand-optimized code, but I believe that applies to code generation in general. The generated code is certainly not tuned to be beautiful, but haxe provides source-mapping to minimize the occasions where you actually have to look at it.

Does it support using 3rd party .JS libs like jQuery or Moo framework? How?

In haxe you define externs to interact with native libraries. This is actually not strictly necessary and you could completely work in dynamic mode, but it provides full type-safety and is easy to do. Check out http://www.haxejs.org/externs/ for some examples.

Haxe/NodeJS

Does haxe support every feature accessible from NodeJS? Buffers? Sockets? Crypto? Can a full NodeJS server be built with haxe with no limitations?

Answer

Are there any drawbacks? Like inefficient code generation by the Haxe compiler or extra code added or anything that's worse than hand-written JS code?

Answer

What if the Haxe wrapper for a certain function/class does not exist, how do you access it then? Would it still be strongly typed?

Answer

Does it support using 3rd party NodeJS modules? 3rd party libs like optimist or socket.io? How?

Answer

some general remarks regarding the questions

Hello, I'd like to clarify a few points. Since, IMO, the quality of the current WP page is very problematic, I've started a new one here User:TOderson/sandbox - maybe that also helps to shed some light on what's going on. Apologies for reiterating the most important aspect a few times in the following paragraphs, but AFAICS it's the source of much of the confusion here.

I'd like to address what I think is a central terminology issue, that also manifests in your questions. The point being about what "full support" in terms of haxe (and actually in terms of programming languages/ runtime environments in general) means. The languages that haxe compiles to are just intermediate representations. Very much like compilers internally transform source-code into several intermediate representations before producing a final result, haxe uses other programming languages as intermediate (or final) representations to achieve the goal of translating a program written in haxe into runnable and/or compilable code that preserves the semantics of the original program. The same is true for other languages. If e.g. OCaml or Java claim full support for the x86 or the ARM architecture, that doesn't mean that the language allows every construct that can be written using the x86 or ARM instruction set, it only means that programs written in the source language can be somehow translated for and executed on hardware with the respective architecture. When Java claims Linux support, that doesn't mean you can use every system call that's available on Linux from Java directly, it just means that a JRE for linux exists.

Full support implies that the haxe language, as well as those essential parts of the standard library that live in the top-level and in the haxe.* packages are usable. It does *not* mean that each and every feature, paradigm and construct that exists in those target languages is supported in haxe itself, for instance:

Haxe has support for higher order functions (HOFs), that is, functions are first-class values, and you can pass them around in variables as arguments to other functions. Now let's assume that a target isn't fully supported yet and everything is in place and working except for HOFs, which are not implemented yet. In this scenario, not every haxe program could be translated to that target. Programs that use HOFs can't, and hence it would be wrong to call such a target fully supported.

To look at it from the opposite perspective: Haxe doesn't support the goto statement. Some of the target languages do, others don't, and their haxe implementations might or might not make use of the goto statement, but as long as any haxe program can be translated into semantically equivalent programs in the respective target language, the target is fully supported, regardless whether haxe, as a language, supports the goto statement or not.

Haxe is a mult-paradigm language. It's not a prototyped language, though, and it doesn't have any concept of prototypes. Still, since any haxe program can be translated to JS, JS is a fully supported target.

Now, let's take a look at what would happen if "full support" meant what you seem to imply by asking the questions about the target languages the way you do, that haxe supported every feature of every target language: Everytime a new language backend would be added to haxe, haxe would be required to incorporate the totality of the available paradigms, concepts and constructs into the haxe language. We'd have 4 "public" keywords with different semantics from AS3, C++, C# and Java by now. There would have to be C#-style, Java-style and C++-style virtual and non-virtual classes, Java inner classes, C#-style partial classes as well as JS-style and AS2-style prototypes, C++-style structs, unions and templates, C#-style generics and Java-style generics, explicit memory management as well as garbage collection - the haxe language would be a conceptual mess with thousands of keywords and absolutely intractable semantics, and it would have to be able to translate that mess into semantically equivalent code to all supported targets, IOW an ultimate nightmare both from a developers and a language-design perspective.

Instead, haxe has its own semantics, and as soon as it can be compiled to some language in a way that preserves these, and the minimum required cross-platform part of the standard library is supported, that language can be added to the list of fully supported targets.

That being said, haxe actually does have support for target-specific constructs that can be used via so called "magic" functions and metadata annotations, which for example allow to insert arbitrary JS, PHP or C++ code (that may or may not be valid haxe code) into functions for the respective target, but these are optional and make the code non-portable. To address these platform-differences, haxe allows conditional compilation, so you can use conditionals like #if js .. #elseif cpp .. #else .. #end to create sections of code that are only included if you compile to the respective target.

HTH, TOderson (talk) 07:38, 25 April 2013 (UTC)

Great points, never thought of it that way. I was talking more along the lines of .. if I picked up Haxe as a multiplatform AIO language, I should be able to do the "usual basics" on each platform. In AS3 it means graphics and 3D and whatnot. On .NET it means working with 3rd party libs, DLLs, and all the other powerful things you can do with .NET. With NodeJS you should be able to create a functional server and use all the platform classes and 3rd party modules. Etc. I just mean that the platform should work, and should work for more than just "hey! I got haxe generating a sample C++ file and it actually compiles for platform X!". I don't mean to be harsh or mean, just saying that when haxe is advertised as a "supports-all-your-favorite-platforms tool" it should, well, support the platform's important features. I completely understand your point and sympathize completely, a language that tried to simply merge every construct from every language would be a usability disaster. I was just refering to functionality as opposed to semantics/language features. -- Tom Jenkins ^(reply) 17:31, 25 April 2013 (UTC)

Just saw your version of the haxe article in your sandbox. I think its truly fantastic and very encyclopedic! Copying suitable sections over immediately! -- Tom Jenkins ^(reply) 17:32, 25 April 2013 (UTC)

Thanks. (couldn't figure out how to put more than one paragraph into an indented reply, continuing below)

However, I'd have wanted to ask you to wait with copying it over. The existing article is just too bad, it's confusing, horribly arranged (e.g. mixing up history with architecture), partially plain wrong, uses non-standard terminology and whatnot. Having correct bits sprinkled into that mess here and there doesn't improve the situation. As you've experienced yourself, it can be tough to understand what haxe is about, how it works etc. and the best way to address that is writing up a well-structured article with clear and unambiguous terminology. Also, in my draft (!!) article there are many rough edges still, especially the type sections with the code examples aren't complete and not quite as descriptive as they should be, there surfaced a few remaining issues WRT GADTs that need to be addressed before haxe can claim full support for them etc.

Regarding your changes: The merged code example given for classes/interfaces (your version) is wrong, it wouldn't compile. functions in interfaces can't have implementations. I only copied that as a stub to turn it into something more useful later, e.g. for demonstrating the various components that classes can contain, like static and instance variables, properties with their various access modifiers, static, instance, inline functions, metadata etc. The color example from the website also is neither particularly telling nor an idiomatic use for ADTs. Your use of the term "module" in the context of targets is misleading at best, a module in haxe has a well-defined meaning that's totally unrelated to targets. The point I'm making in the draft, that "target" itself is an ambiguous term that is used for different only partially related concepts is *very* useful information for someone looking at haxe, since it's widely used, and most often without providing sufficient context.

More general: One of the great issues haxe has is how it presents itself to the world. It's a language with a type-system (almost) as advanced as those ocaml or haskell offer, which are often referred to as "academic" languages, and which attract completely different people. Haxe doesn't have that reputation and moreover presents itself like a toy. I don't see any value in contributing to an article that adds to that impression. If anything, the prose bits about authorship, history etc. should be added to a well-structured article somewhere, not the other way 'round. TOderson (talk) 22:18, 25 April 2013 (UTC)