What are limitations of HaXe compared to writing in target languages alone?

[GeneralLuken .]

Ok, it is easy to find what HaXe can do, but it is really hard to find what are its limitations. I'm suspecting that it is impossible to write in HaXe literally everything you can write purely with PHP or AS3, or am I wrong? And if I'm right what are limitations you know of?

[Simon Krajewski]

Some things are harder to get right than others and some you will have
to approach differently in haxe than you would otherwise in the target
language. But at the end of the day, all these languages are
turing-complete and it comes down to accessing their various APIs.

Simon

[j...@justinfront.net]

Having used both AS3 and Haxe for flash for commercial projects, there is no difference for me with the following exception:

Pro Haxe

_______

If your project is currently AS3 and large it may take effort to change it to Haxe.

Using AS3 is frustrating because it's not properly typed, with hacks like Vector and functions do not have proper typing.  The reality of using AS3 is that you spend a lot more time debugging at runtime and it is much harder to code in a type safe manor to the point where you often don't.  For coding, once your used to both languages, it's not nice to go back to AS3.

It's a lot more work to create AS2 and AS3 code bases for projects like multi-language banners where some markets may need slower AS2 versions.  If a project requires AS2 then really you should code it in Haxe, if it requires AS2 and AS3 then you would be silly to consider anything else.

If I code in AS3 my code is throw away not useful tomorrow for other projects not in flash, if I code in Haxe then the any logic is transferable to other targets.  I can even code Canvas stuff that will work with slight changes some typedef to work in Java and JS !

I have found libraries written in Haxe to be less OOP java style so something like hxswfml for runtime font parsing was more complete and much easier to amend than the AS3 equivalent was, although you can write similar code in both languages I suspect Haxe encourages better structures.  Good languages allow you to code better, Haxe seems to do this.

In Haxe you can reach in and change third party libraries with reflection something that is not really possible in AS3?

Haxe has stuff like Haxe remoting so it is very good at talking between targets, really is amazing.  |deal for AS3/PHP projects.

Pro AS3

_______

If your project is currently in Haxe and large it may take effort to change it to AS3

Timeline code should be coded in AS3/AS2 but I don't see any problems mixing AS3 and haxe within a project.

Flex is not something I see used much outside of banking and generally I am not a fan.  I doubt it would be particularly sensible to convert a flex project with components to Haxe, so if a project is currently written with lots of flex it is not suitable to port it to Haxe unless you plan to target Javascript.  Attempts have been made to port Flex to Haxe and it was found that the AS3 used, was too hacky to transfer, from talking with the people who tried it appears that Flex took advantage of undocumented player features.  I think maybe you should be porting your Flex for future proof anyway.

If you have a 3D project you should probably use Away3D AS3 you can control it with Haxe but currently there is no haxe 3d solution for flash that offers the same workflow from 3d package to flash movie, since stuff like prefab is really cool.

It's easier to use e4X in AS3, so if your project is only going to be in flash and you have to use XML then parsing xml may have some advantages in AS3, but this is debatable.

More Libraries are available in AS3, and the more complex ones of thoughts, may need slight adjustment to work well with Haxe, but normally you can use them in either AS3 or Haxe interchangeably.

Cilents prefer AS3, developers who used both often prefer Haxe.

Pro Haxe and AS3

I think often mixing AS3 and Haxe can be most practical.  Then most of your logic codebase can be re-targetable Haxe but you don't have to rewrite all the AS3 libraries when re-targetting you just swap them for say a JS native library that provides the same functionality.  I have mixed AS3 and Haxe in Air projects and in facebook social games for different reasons but they work well together.

________________________

I think considering Haxe as an Alternative and asking about its limitations is a misunderstanding of it as a Technology.

Haxe is a "Complementary" or "Practical" technology you don't have to move all your code from language X to haXe it's just a really good idea to write new code in Haxe the reality is - Haxe is a better language to code your target in, but also a complementary language to code your target in where you can still use good code that is not written in Haxe.  Once you start to understand this then the reasons not to start using Haxe seem to disappear.  Certainly with Flash, I have not found there is anything I could do in AS3 that I can't do better in Haxe it does not have any limitations if you approach it as Simon suggests.  I have never felt Haxe to be a limiting language like AS3 or PHP are.  The strangest thing about Haxe is the reality that many users perceive there must be a catch because otherwise why is everyone not using it, the reality is the only catch is this perception.

On 21 Sep 2013, at 13:26, GeneralLuken . wrote:

Ok, it is easy to find what HaXe can do, but it is really hard to find what are its limitations. I'm suspecting that it is impossible to write in HaXe literally everything you can write purely with PHP or AS3, or am I wrong? And if I'm right what are limitations you know of?

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/groups/opt_out.

[GeneralLuken .]

Thanks for insights. I can imagine that writing in HaXe and targeting PHP, may be limitating in a way, that it's probably just obfuscating code, and it would be rather handy to have clean PHP code for future developers etc. I guess it doesn't matter that much in "compilable" languages, if client/user doesn't have access to source code anyway. I'm certainly giving it a shot, but probably for PHP I will stick with PHP for that matter.

Could you give an example of nature of adjustment that is sometimes needed? What kind of things HaXe cannot sometimes digest?

[j...@justinfront.net]

[j...@justinfront.net]

>
> Could you give an example of nature of adjustment that is sometimes
> needed? What kind of things HaXe cannot sometimes digest?

Some libraries expect you to inherit the Main class, since haxe sets
up boot this is not practical, normally this is not too hard to adjust.

> I can imagine that writing in HaXe and targeting PHP, may be
> limitating in a way

I have read some PHP books, well never seem to get too far always
looked rather a mess of a language, I have coded in Haxe php but
nothing serious, however normally the same code can normally run in C+
+, Neko, Java, so I don't really feel it is limiting! I can't
imagine why you would code in pure PHP unless you had to. Generally
with PHP target best to develop with Neko and then compile to PHP from
time to time to make sure the code works but debugging in Neko is
simpler and normally the same Haxe code as PHP.

Haxe allows me to code complex stuff, easily for target languages I
have never coded. Obviously the more you know about the target the
better but Haxe does allow you to abstract to high levels quicker, it
lets you get to the coding faster and allows you to wrap round silly
aspects of a target making life simpler. I may have to learn PHP but
I would only do that to get work not to do work!


Maybe someone using Haxe for PHP can comment on day to day use of Haxe
PHP verses pure PHP. But I guess the main advantage is you can move
your code between neko, node and PHP.

[Nicolas Juneau]

Hello GeneralLuken,

I use Haxe mainly for PHP development (not for commercial use, however). Consider however that this is a personal opinion, not a formal analysis. If there are some PHP developers out there that could add comments or counter what I have written, that would be great. Don't take this as granted.

On the plus side, Haxe adds a compilation step that PHP doesn't have. For example, if you develop in pure PHP, the IDE you use performs syntax checking. Therefore, depending on the chosen IDE, you may not catch all syntax errors (especially since the PHP language is very "loose" and that some IDE have a hard time detecting what is an error and what is not). When using the Haxe compiler, the compiler itself is able to detect syntax errors. Therefore, no matter what IDE is used, there is a minimum of validation done before runtime. Moreover, the fact that you can execute macros at compile time gives you some interesting options.

Haxe is also strongly-typed. This gives type-safety at compile-time, whereas, in PHP, there's not much type-safety at all. Again, this adds more validation to your code when it's compiled.

I also like how Haxe takes care of classloading. In native PHP, namespaces and classloading are supported, but it doesn't seem very standardized. Depending on the framework you use, you may have a hard time having automatic classloading everywhere in your application. In Haxe, it's all taken care of.

On the down side, debugging will be harder in Haxe than it is in native PHP. If you use XDebug with an IDE to debug your code (with "stepping" support), which is insanely handy, you may not be able to do so with Haxe. If there's a Haxe developer here who could confirm that statement, that would be nice. You can always use "trace", but it is far from being as efficient as a proper debugger.

Finding bugs can also be harder because of the fact that Haxe generates code. If you have a bug, is it a bug in the PHP language? A bug in the code that the compiler produced? A bug in the Haxe code that you have written? There are some added steps there.

Also consider that the PHP API is very versatile and very diversified. You may not find everything you want in Haxe. For example, support for SOAP Web services, support for certain cryptography algorithms or cryptography tools (certificate/signature validation)... You may find some libraries that do it, but in a production environment where you must ensure the viability of the technologies and libraries you choose, this may not be an option.

I hope this helps you determine what kind of adjustments you have to go through when using Haxe. For my part, I find the Haxe language syntax excessively pleasant compared to PHP, but on the other hand, you have to compromise on the wide array of features that PHP offers.

[Tarwin Stroh-Spijer]

I've been using haxe for PHP output for years now, on everything from small sites, our own CMS and now a large silicon valley startup. Compared to simply writing PHP your code is likely to be a lot cleaner and easier to follow. At least for myself haxe outputs code that I would be way too lazy to write myself. It also means I don't have to have php.net open at all times to remember if I need to do "haystack, needle" or "needle, haystack" all the time.

Wrapping other PHP libraries in externs is really easy as well. Also, being able to do compiler directives and then have in your code something like:

#if debug_db

  Logger.trace(db.lastSql);

#end

Is REALLY useful for debugging code, profiling etc.

Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
cell: +1 650 842 0920
_______________________