Why aren't Multi-Platform Programming Languages popular?

The point may be this sentence from the site you linked to:

platform-specific libraries : the full APIs for a given platform are accessible from haXe

Which means, once you write a haXe program targetted for .Net, for example, it's equally different to port it to the JVM, say, as if you wrote it in C# right away.

Because the value in those platforms are not so much a particular language like C# or Java, but the (more or less) well founded APIs.

To avoid this, one had to have a über-API that maps to the choosen target API on demand. Not impossible, nor uninteresting, but much, much work to get it right. (Usually, you'll find that just the corner of the API you want to use is not yet implemented or portable.)

Projects with difficulties like this: GNU java compiler (weak API coverage), wx (platform independent graphical API, it has gained some popularity, but it's never near completion AFAIK.)

Speed : a good programmer will be able to code faster code than a code that's translated from a higher language

Language specific features : Some of the language specific features can't be used because you wont be able to comple them to multiple targets

Need : As a programmer you pick the right tools for the job. There isnt any advantage in compling to other languages that dont have all the features you want. For example if I wanted to write something that would work on linux and windows I would use java. Being able to comple to C++ as well wouldent help.

Hardware specifics : for hardware like phones to access most of the hardware or to use the full power of the phone you need to code in the language the phone understands. Javascript + HTML don't always cut it.

Im assuming from the body of the post you meant multi langage rather than multi platform in the title. If you want multi platform there are lots of alternatives.

I suppose, when you mean crossplatform, you speak of things like this (press space for something to happen):

• haXe/flash10
• haXe/js using jeash
• haXe/flash10 and haXe/js at the same time. The left half being js, the right being flash (you can verify by right clicking).

Using jeash, the code for the first and second demo is virtually identical, only the second demo must be compiled with --remap flash:jeash, to remap the native flash player API onto the jeash abstraction layer.

The same is also possible using nme to use the flash player API on various other devices. Therefore you can just as well target iOS and Android with the same code, as seen here:
More on that on nabble.

To sum up haXe's problem:

• haXe is still growing and maturing. And its growth is always ahead of its maturity. You have a fair amount of features subject to change. A lot of really funky cool stuff, that just ain't documented. And so on.
• haXe hasn't reached critical mass yet. Even though there is a community big enough to get all the support you need, it is very far away from becoming a main stream language.

It's young and small. It's also what makes it fun. Personally, I love haXe, even though I can think of a hell lot of things I would change about it, if I could. But it's exciting and challenging.
The thing is, most people in our industry don't want excitement or challenge. I am quite often denied to write a project in haXe, simply because its future is considered relatively unsure (a fear that is understandable, yet unneeded IMHO) and because it's hard to get a replacement for a haXe coder.

And at the bottom line, this applies for most technologies like that: They are small, they are young and therefore it's hard to get people for them, it's hard to tell where they are headed and whether they will prevail. Plus you have to keep up with their pace.
For bigger companies, this is basically a no-no.

First of all, Language is a matter of choice. There are numerous developers with able qualities in various language but they stick to one with a core programming language TAG. Next thing is that these languages are still pretty new, people haven't yet adapted to them. This will take some time, like the other languages did.

Other issue can be performance and adaptability. IMO, Languages written for particular framework are much more capable and able in specific framework. All in all, it's a time driven issue. If such languages evolve good over time and provide stable development environment, along with better community, we can expect things to change.

As a general rule, a code written for a specified platform will perform better and have less issues than one supposed to be multi-platform.

If you stick to one platform, you only need to debug your code for that platform, and you know the code you wrote. By using a cross-platform compiler, you don't know what kind of specific-platform code it will add, and if it will work as expected.

Even if you use a specified programming language or software able to make it compatible for different platforms, you still have to make sure the code don't break after the targeted platforms update, cause it may take time before a fix patch for the software you use will be released.

Also, the code you write for specified platforms will be optimized, and won't have additional useless code just for the sake of compatibility, so it will be easier to maintain, as long as you have the resources to differentiate the code for each platform (you might need different programmers for example).

It really depends on what are you needs.

In a web context for example, you really need to have cross-browser compatibility code, also counting existing mobile devices and the new ones coming out. You also always need backward compatibility (IE anyone?), so there's a lot of code you have to bring along the way in future releases.

Frameworks are a great help and are really effective, at the cost of a bigger code library, you can develop safely cross-browser compatible code.

There is always an adoption curve for new technologies / ideas / languages: first early adopters, then mainstream adopters, then late adopters. In the beginning, when the idea is new and unproven, it has little to no tooling / IDE / framework support and its implementation is (usually rightly) expected to be buggy. So only adventurous kinds play with it, and companies are very reluctant to base their business on these, however interesting they look. Eventually, if the idea is tested and proven, it gains momentum and followers, its bugs are shaken out, its features and tool support is improved, so it gradually it may become feasible as a production development platform. This process takes years though.

In summary, there may not be anything wrong with these ideas, just they may need time to spread.

Specifically the idea of compiling from one higher level language to another is nothing new - writing the first compiler for a new language as a C preprocessor is a known trick since the 70s. I fail to see what actual advantages this is supposed to offer over existing VM-based languages - but then again, I am totally new to the concept :-) I also have some doubts though how this can work out in practice with so many different platforms, each having its own limitations and idiosynchrasies. It may result in ugly little incompatibilities between compilations of the same code to different platforms... Only time will tell this.

First of all, most languages are multi-platform. For any usable platform, there is a C compiler. JVM and all languages based on it runs on plethora of platforms. There is also Python version for any currently used platform. And the list goes on, and on.

Of course in case of iOS, the limitation is not the platform itself, but Apple's policies not allowing to use above without jail-breaking.

There are cross-platform tools, like for example Unity, which go around this problem in a way similar to HaXe — by code generation.

So actually your question should be "Why isn't HaXe popular?". For such a question my guess would be, that it's just adding unnecessary extra layer of complexity, and extra exotic language to learn. It's at disadvantage with other cross-platform solutions, which instead of inventing whole new language, use well established one and translate/cross-compile that to native one for the platform.