It's show time for me, and I need your help.
152 views
Skip to first unread message
Itzik Arzoni
Nov 30, 2015, 6:59:36 AM11/30/15
to Haxe
Hi guys. I'm not an active member of this community, and not even a full time Haxe developer, but it's now my time to shine.
After Presenting Haxe to the R&D manager of my section in the company, he really liked it and scheduled a presentation for this Thursday in front on all of the Tech heads in my (1600 workers) company.
I hope I get all of it straight, I've read a TON about Haxe.
Anyway, what I really need now is some kind of a killer argument.
Something that will answer questions like "Why do I need Haxe if I can use TypeScript?" or "How reliable is it for server?" or "If it compiles to all the languages, that it's probebly only pretty good, because it's not specialized." or a question I've heard today: "What is the tradeoff, and is it worth it?".
Thank you for the help.
I would be really happy if this thread will evolve into a discussion.
Itzik
David Elahee
Nov 30, 2015, 7:28:15 AM11/30/15
to haxe...@googlegroups.com
Hi !
First and foremost, if you are 1600 people, you might want to suggest to invite an Haxe expert for a little consultancy. It would smooth out every bit of the transition/explanation.
Second, here is the Unique Selling Points for Haxe, I humbly use :
1- If Haxe is good for million dollar companies' management like Tivo, Massive, Sony, Lego, Disney, Nickelodeon, it should be okay. (see http://haxe.org/use-cases/who-uses-haxe.html for more kickass )
2- If it's good for Game Of The Year like Paper Please or first class Indie Game developpers like Terry Cavannagh, it should be okay.
3- If it's good for Motion Twin and its 30+ millions of users, for both client and server side since 14 years it should be okay.
4- Haxe is fairly easy to pull back and in since it does not lock you in technologies but rather widens the array of technologies you can use within a single mind frame.
5- Haxe is morphing to your usage. It is not generic. Haxe will always ensure you can access to the fastest idioms if need be. With the Magic API and the macros, there are always door's open.
Lastly, I would say that choosing Haxe is a leap of faith, it means you have faith in a true OSS ecosystem and have faith in your capacity to give back and exchange with a very passionate community.
Good luck !
--
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/d/optout.
David Elahee
Justin L Mills
Nov 30, 2015, 7:45:48 AM11/30/15
to haxe...@googlegroups.com
some more points / similar points.
6 - For the Typescript advocates in your company, I would suggest they read
http://blog.onthewings.net/2015/08/05/typescript-vs-haxe/ it should make them realize what they would be missing out on.
7 - Haxe provides some of the fastest running mobile solutions on the market, while providing some of the best interactive code approaches, with indifference to being tied to any particualar make of phone or any future limitation or bias of these corporations ideas on tooling. Since you can still code Haxe as much or as little in the way the phones are predisposed.
8 - Using one language that work well, makes communication between many systems and developers much simpler and effective, especially when you can still mix it with native solution and historic code relatively easily.
6 - For the Typescript advocates in your company, I would suggest they read
http://blog.onthewings.net/2015/08/05/typescript-vs-haxe/ it should make them realize what they would be missing out on.
7 - Haxe provides some of the fastest running mobile solutions on the market, while providing some of the best interactive code approaches, with indifference to being tied to any particualar make of phone or any future limitation or bias of these corporations ideas on tooling. Since you can still code Haxe as much or as little in the way the phones are predisposed.
8 - Using one language that work well, makes communication between many systems and developers much simpler and effective, especially when you can still mix it with native solution and historic code relatively easily.
Dan Korostelev
Nov 30, 2015, 7:51:25 AM11/30/15
to Haxe
I would say the killer argument depends on your use-case.
понедельник, 30 ноября 2015 г., 14:59:36 UTC+3 пользователь Itzik Arzoni написал:
If you compare TS and Haxe, there's a great article by Andy Li on that topic: http://blog.onthewings.net/2015/08/05/typescript-vs-haxe/.
I personally use Haxe/JS quite a lot and I would say Haxe provides much more of compile-time safety, concisensess and performance than any compile-to-js language, thanks to its powerful type system (abstract types, enums, etc.), macros (we generate a lot of code so we don't repeat ourselves) and inlining (to get rid of extra function calls). That applies to any target though, not just JS.
As for the "jack of all trades", it's a valid concern, but I can say Haxe tries it's best to achieve maximum performance and compatibility with the target platform while still being a superior language, and even for some complicated cases - there is "magic" that allows you to inject native code inside generated one, so you are never too far from your target platform. I use Haxe/C# (together with Haxe/JS) quite intensively and the generated code is good enough not to care much about it, especially if you consider the benefits. It may be different with Haxe/C++ since it basically contains its own run-time with a GC, but I can't tell much about it.
You can read my article about how we got to using haxe in our company: http://nadako.tumblr.com/post/113390739725/a-success-story-for-haxe
понедельник, 30 ноября 2015 г., 14:59:36 UTC+3 пользователь Itzik Arzoni написал:
whitetigle
Nov 30, 2015, 8:59:12 AM11/30/15
to haxe...@googlegroups.com
Being one of the more ancient user out
there ( as a former associate at Motion-twin with Nicolas ) I can
say that Haxe has always been the ideal tool for whatever project
I had to work on: MMO web games, native desktop and mobile apps,
web sites, datadriven apps, hardware related projects and so on...
The most important points so far for me have been:
- stability of the language itself and its core API
- functional approach
- very fast compiler
Last but not least: my killer argument would be: "one language to rule them all" because It's easier to share the same language and same culture. There will always be C++ specialists and Java gurus and JS fans but they can now all share the same API and protocol using Haxe. What a relief to make sure the core logic of an app is always stable because everybody understands it. Then we always need specialists and that's OK because with Haxe we can allow them to make some great low level calls while not touching the core API.
BUT... but..
Haxe is a language for developers with some experience. It's powerful and needs time for training. (+1 for real expert consultancy)
The lack of exhaustive samples make it very hard to use for newcomers. And to me that will certainly be its weakest point.
Real-life example: using stackoverflow I am never stuck on scala. While newcomers to haxe are not that lucky.
(FYI: http://sogrady-media.redmonk.com/sogrady/files/2015/01/lang.rank_.plot_.q1152.png)
The road to adoption MEANS good documentation and ready-to-use samples. While on Scala you could use activator to get started (although, ok it sucks), I think this approach, that OPENFL allows for native games, would certainly prove a great move for the Haxe ecosystem if generalized:
- you want to make a simple http-rest server? Ok let me show you
- you want to make a mobile game on iOS? No problem let's get started
- you want to use a nodejs+GPS+leaflet? Ok that's so easy!
- you want to make a Redis/MongoDb/nodejs Real time server ? In a minute!
- you want to make a great data driven cordova app on windows phone? Sure!
- you definitely want to make the most of that new MIDI device you just bought for your studio? Let's do it!
Because that's the power of haxe: it wraps itself like a fast and versatile snake around pretty much every project on earth.
So make sure the point on documentation gets properly addressed and it should be fine :)
François
The most important points so far for me have been:
- stability of the language itself and its core API
- functional approach
- very fast compiler
Last but not least: my killer argument would be: "one language to rule them all" because It's easier to share the same language and same culture. There will always be C++ specialists and Java gurus and JS fans but they can now all share the same API and protocol using Haxe. What a relief to make sure the core logic of an app is always stable because everybody understands it. Then we always need specialists and that's OK because with Haxe we can allow them to make some great low level calls while not touching the core API.
BUT... but..
Haxe is a language for developers with some experience. It's powerful and needs time for training. (+1 for real expert consultancy)
The lack of exhaustive samples make it very hard to use for newcomers. And to me that will certainly be its weakest point.
Real-life example: using stackoverflow I am never stuck on scala. While newcomers to haxe are not that lucky.
(FYI: http://sogrady-media.redmonk.com/sogrady/files/2015/01/lang.rank_.plot_.q1152.png)
The road to adoption MEANS good documentation and ready-to-use samples. While on Scala you could use activator to get started (although, ok it sucks), I think this approach, that OPENFL allows for native games, would certainly prove a great move for the Haxe ecosystem if generalized:
- you want to make a simple http-rest server? Ok let me show you
- you want to make a mobile game on iOS? No problem let's get started
- you want to use a nodejs+GPS+leaflet? Ok that's so easy!
- you want to make a Redis/MongoDb/nodejs Real time server ? In a minute!
- you want to make a great data driven cordova app on windows phone? Sure!
- you definitely want to make the most of that new MIDI device you just bought for your studio? Let's do it!
Because that's the power of haxe: it wraps itself like a fast and versatile snake around pretty much every project on earth.
So make sure the point on documentation gets properly addressed and it should be fine :)
François
--
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/d/optout.
-- -- François Nicaise www.francoisnicaise.fr Freelance Developer / Designer https://www.linkedin.com/in/fnicaise
Itzik Arzoni
Nov 30, 2015, 9:24:17 AM11/30/15
to Haxe
Thanks for all your answers.
I don't know if my presentation will lead to adoption of Haxe, I sure hope so. If so, I will point them to the site where it states that they can send an e-mail to haxe foundation for a real expert consultant.
About your points:
* I am planning of talking about the companies that are using Haxe for a long time. I guess that the argument of "If it's good for them, it also good for you" is pretty effective, I just want it to be a conclusion argument, after having them convinced by the substantial points
* I've read Andy's article, but except of asking people to read it, I can't make a one line "Wow" argument out of it. BTW, I've already sent them the article.
* About: "Haxe is morphing to your usage. It is not generic.". I'm trying to make this point. But can't really answer the question "how is it so?" because "one language to rule them all" sounds very much like "this language give medium results in a lot of other languages", which I know that for Haxe it isn't so.
* About: "Thanks to its powerful type system (abstract types, enums, etc.), macros (we generate a lot of code so we don't repeat ourselves) and inlining " - That's a good point. I am giving examples (from try.haxe) of all these features plus the static analyzer.
* About "- functional approach". Sorry, this is probebly my lack of understanding, but the big advantage of Haxe on Javascript is it's being a strict type OOP language. What do you mean by "functional approach"?
I've noted all the rest of your points, and see if I can fit them in the presentation.
I've also made it using Perzi, just so I can show them a working tool that was made by it.
Thank you. Keep the ideas comming :)
MJ
Nov 30, 2015, 9:35:33 AM11/30/15
to Haxe
Check also this video for ideas: https://youtu.be/CupIdO-GpVg?t=1833
David Elahee
Nov 30, 2015, 9:37:29 AM11/30/15
to haxe...@googlegroups.com
'Bout ""Haxe is morphing to your usage. It is not generic."
1- Native API's are easy to integrates via externs, for example if you want to use a shiny new XML Api it's easy as writing externs
2- If externs are too complex Native API's are easy to tackle using Magic ( http://old.haxe.org/doc/advanced/magic )
Even in cpp I recall prototyping vector.blit through calling memcpy via raw Magic calls.
3- The macro system allow to go vey far customizing your workflow.
Preprocessing and code manipulation are always a good way to build your own nest.
4- The haxe ecosystem is open source and people are easy to reach via mail or social media, so tuning for your needs usually is fairly easy.
5- Most of the time haxe code translate fairly closely to what you would have hand written unlike code generators it really is transliteration.
What I mean is that Haxe will always give you means to bypass its own limitations. And that's awesome :)
--
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/d/optout.
David Elahee
Juraj Kirchheim
Nov 30, 2015, 9:43:55 AM11/30/15
to haxe...@googlegroups.com
Hey Itzik,
without breaking any regulations you are bound by of course, can you give us more detail about what you wish to use Haxe for? Haxe is extremely versatile. I think it would help your pitch to focus on advantages really relevant to the software you are looking to create.
Best,
Juraj
Haxiomic
Nov 30, 2015, 9:47:50 AM11/30/15
to Haxe
What sort of projects will you use it with?
Before I started the current project I'm working on I had a good long look at typescript and ended up choosing haxe. One reason was that typescript didn't feel as mature as haxe, but more importantly, it lacked important features:
1. One of the biggest killer features for me is compile-time macros
An example that's coming up a lot in my current projects is blending external files with the source code. I've got some google earth files that I need to extract some paths and locations from. Traditionally, you'd bundle the google earth file with your assets and read and parse at runtime.
Now say I want to extract and use a specific path named "migration_path", I'd need to know the contents of the google earth file to know it's in there before compiling so I know there's not going to be an error at runtime. With macros, you can parse the google earth file at compile time (it's just xml), extract the paths and then deliver just the bits you use into the source code. This means the compiler will let you know if the path doesn't exist, better still you can see all the available paths with autocomplete, which makes keeping your code and your assets in sync muuuch easier. Further more, you no longer need to load and an extra file at runtime and your code is generated with just the bits you use.
I made a gif to demonstrate http://g.recordit.co/kO7ACr1LVC.gif
I do something similar for managing shaders: i've got a directory containing .vert, .frag and .glsl files, I set up a macro (very simple to do) that reads the shaders directory and delivers the available shaders for autocomplete.
So with macros you no longer need some complex build system made of separate tools, your build system can all be handled within the code, and all in the same language.
2. Flexibility
I've had to put together a bunch of different command line tools for data processing in this project. Some tools need to process hundreds of images, others just json files. Now the image processing tools need to run as fast as possible otherwise we're looking at hours worth of processing time, so in this case, I choose c++ as the target and spend a little bit more time compiling the tool so we can have a much reduced runtime. With the other tools I choose the neko target so we get super fast compile time. This isn't a choice you'd get to make in any other language, eg: python lets you write your code quickly, but at a performance pentalty, c++ lets you run your code quickly but at a write-time penalty.
This offers another benefit: you get to pick and choose the best of the different ecosystems. Say I needed to do some statistical data processing, well python is used heavily in the data sciences and there's a lot of libraries and code out there I'd like to use. So for this tool I can compile to python and use externs for the libraries I want.
Itzik Arzoni
Nov 30, 2015, 10:23:30 AM11/30/15
to Haxe
Hi Juraj, the main problem everyone is facing right now is that the flash player is really dead (sadly, because I develop flash for 10 years). So all of the products departments (4 or so, which are pretty independent) are trying to find solutions to unify the desktop and mobile products using JavaScript. They are not interested in native apps, and the server side is already developed.
I would love to recommend OpenFl, but it require a bigger leap of faith than just relaying on making a javascript client. Most of them are already considering solutions like TypeScript + Angular.js (for example).
I know for a fact that to develop for JavaScript target in Haxe, I will need to learn JavaScript, which is very desirable for me.
So the presentation should be first to capture their imagination without the interest, while trying to hint them about thinking of Haxe as a best solution.
So the presentation should be first to capture their imagination without the interest, while trying to hint them about thinking of Haxe as a best solution.
Hi, Haxiomic. Your points are very good. I'll surely speak about them.
Philippe Elsass
Nov 30, 2015, 10:44:27 AM11/30/15
to Haxe
* First clear any ambiguity
Haxe JS is about doing DOM/Pixi/NodeJS stuff like you'd do in TS/ES6 but using the Haxe language.
Eg. OpenFl is just a toolchain/framework on top of Haxe.
* Easy to learn
Getting into Haxe isn't harder than TypeScript if you've used an OO language before. It may be arguably easier than ES6+ in some respect.
* Reflection
A company I know who evaluated TS VS Haxe chose Haxe because at run time TS is a lot weaker in terms of Reflection: interfaces do not exist at run time and thus run time type checking (is/cast) is much stronger in Haxe and it allows much better dependency injection methods and stronger code integrity.
* Conditional compilation and classpath
Inexistent in TS/ES6, conditional compilation and classpaths allow to easily switch implementations without having to use very complicated mechanisms. I think this is a rather important one compared to the relative mess that require/node_modules is.
* Pattern matching
Ok this may go a bit over the head of Haxe beginners but it's brilliant
* Efficient generated code
- clean code generation (try reading the ES6 fancy feature converted to ES5)
- constant propagation
- fast dead code elimination
- remove all the debug-related code from the codebase using a compiler argument (eg. drop all traces).* Macros
TS don't have macros, babel has some really rudimentary system - nothing as mature and capable as Haxe.
* Modularity and fancy toolchains like Webpack are possible
I also have React hot-reload in progress.
--
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/d/optout.
--
Philippe
Philippe Elsass
Nov 30, 2015, 10:48:57 AM11/30/15
to Haxe
In any case saying that JS or TS sucks is bad (and a lie): TS language and tooling have become really impressive.
--
Philippe
Justin L Mills
Nov 30, 2015, 10:53:57 AM11/30/15
to haxe...@googlegroups.com
Itzik
Openfl / NME is not much of a leap of faith, it's actually a very prudent step.
1) AIR the second most used approach for Android development is easily target when you compile Openfl to flash, and you have 10 years of expertise in flash you can transfer. Currently there is starling, robotlegs and away3d all ported to Haxe.
2) Flash code bases can be ported to Openfl very easily.
3) Rapid test and deploy to mobile as C++ code with no changes, recompile Openfl to NME and from a terminal deploy over the web to test device via https://play.google.com/store/apps/details?id=com.acadnme.launcher&hl=en_GB to get a 10x possible improvement in speed.
4) For webkit Node.js application you can reuse all the Haxe business logic and just abstract the views. And easy to use Angular http://www.haxejs.com/#!/getstarted I expect you can even use npm the 'node js workflow' installer to install a haxe version of angular!
5) When you need more speed you can look at emerging projects like Kha or Snowkit where you might be able to get a bit more performance and still share lots of the logic and libraries.
Currently you find yourself locked by the technology, but if you transfer to Haxe you end up with quite the opposite effect you become more and more open to more technology but allows you to keep a DRY approach and have less developers.
Best
Justin
Openfl / NME is not much of a leap of faith, it's actually a very prudent step.
1) AIR the second most used approach for Android development is easily target when you compile Openfl to flash, and you have 10 years of expertise in flash you can transfer. Currently there is starling, robotlegs and away3d all ported to Haxe.
2) Flash code bases can be ported to Openfl very easily.
3) Rapid test and deploy to mobile as C++ code with no changes, recompile Openfl to NME and from a terminal deploy over the web to test device via https://play.google.com/store/apps/details?id=com.acadnme.launcher&hl=en_GB to get a 10x possible improvement in speed.
4) For webkit Node.js application you can reuse all the Haxe business logic and just abstract the views. And easy to use Angular http://www.haxejs.com/#!/getstarted I expect you can even use npm the 'node js workflow' installer to install a haxe version of angular!
5) When you need more speed you can look at emerging projects like Kha or Snowkit where you might be able to get a bit more performance and still share lots of the logic and libraries.
Currently you find yourself locked by the technology, but if you transfer to Haxe you end up with quite the opposite effect you become more and more open to more technology but allows you to keep a DRY approach and have less developers.
Best
Justin
Atul Kumar
Nov 30, 2015, 5:03:59 PM11/30/15
to Haxe
while I also like haxe and would rather work with haxe code instead of, for example, js any day there are definetely some draw backs which should be mentioned. Like you said I also consider a list of trade offs very important for a presentation which suppose to present a realistic view in considering haxe as a technology stack.
Since there are many pro arguments mentioned in this thread already let me step in and give you some trade offs to consider:
Generated code is not 100% as u would write it yourself: Typescript does much better in that regard. While generated JS code is maybe "good" enough to do debugging I would disagree that when u would decide to drop Haxe afterwards that the generated code is good enough that u would not feel the need to rewrite it so it is more maintanable. That is definetely true for cpp code of course. I do not know much about the other targets. I might be wrong, so anybody feel free to correct me on that.
Using libraries of the native platform will require extern definition files: If u want to use a lot of js libs in your haxe code u will definietely need them. Otherwise there is no big advantage anymore to use haxe at all. If they are not available u have to get your hands dirty and write them yourself. While that is true for typescript as well chances are higher that somebody provides them already since adoption of typescript is higher. For cpp u will need some "glue" code in most cases I guess.
Haxe is still a bit of a niche: It might be a problem if u need some external help in form of freelancers for example. Good luck finding somebody who is profecient in Haxe. I for example do not know anybody personally.
Documentation can be lacking: While the language itself is nowadays very well documented it is not true for many libraries. I encountered that problem especially when I wanted to do some cpp stuff. Try to find some documentation on the cpp Pointer class for example. Or how hxcpp building works (which is important to understand if u want to integrate some c++ libs). Or somebody mentioned to "use kha".. yes, I would love too, but without documentation it is just to time consuming.
Lack of tooling: IDE support could be better. On windows there is FlashDevelop, on mac ur choices are text editors like Sublime or Atom or IntelliJ. While Sublime (and surely Atom) are great for haxe, they are no real IDEs. There is no debugger or fancy refactoring. While Intellij suppose to fill that gap it still feels to rough for me. I always hit some brick wall when I want to use it. U can use a debugger on your generated code though, which works "so so" I would say.
And also I want to leave a few words about OpenFL and targeting Flash: It is not that simple as it seems on first sight. Last time I checked OpenFL uses the native display list when targeting flash. So no Stage3D. That is on mobile in most cases a no go. U could just use the starling lib and use it in haxe, but also the last time I checked u have to patch it and u loose all arguments names of functions when u just use the swc for example (the Haxe Starling port seems very immature to me). That is also true if u just use a jar on the java target platform, btw. So u will need extern definitions again. At least this is my experience, somebdoy might correct me on this again, since I did just try it briefly without much investgating.
So by mentioning all that I just want to help to paint a realistic picture. Not everything might be right, but this is my current perception. I am happy to be corrected if somebody feels like the critics are unjustified.
Most cons are probably a result of low adoption, which is a bit of a "chicken, egg" situation. So I hope your presentation goes well and more people decide to use Haxe, so I can use it more as well! Good luck!
Cheers
Atul Kumar
Nov 30, 2015, 5:53:18 PM11/30/15
to Haxe
I forgot one trade off:
no short Lambdas
.. just kidding.. old discussion. But let me just say one thing: not long anymore and Haxe syntax will look a bit old school just for not supporting that :P
fell free to ignore that comment!
Philippe Elsass
Nov 30, 2015, 6:07:20 PM11/30/15
to Haxe
Kidding or not, I've been coding in Typescript for the last few weeks in a large client project and honestly I really appreciate the short lambdas here (rxjs heavy stuff). There's nothing unreadable/fancy/elite in short lambdas: it just feels right.
And as for async/await, no amount of macro magic will replace the fact that this is missing from the language. Period.
Sorry for going off topic ;)
--
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/d/optout.
--
Philippe
Justin L Mills
Nov 30, 2015, 6:08:26 PM11/30/15
to haxe...@googlegroups.com
Atul
Just some thoughts that might have some truth...
On 30/11/2015 22:03, Atul Kumar wrote:
> while I also like haxe and would rather work with haxe code instead
> of, for example, js any day there are definetely some draw backs which
> should be mentioned. Like you said I also consider a list of trade
> offs very important for a presentation which suppose to present a
> realistic view in considering haxe as a technology stack.
>
> Since there are many pro arguments mentioned in this thread already
> let me step in and give you some trade offs to consider:
>
> Generated code is not 100% as u would write it yourself: Typescript
> does much better in that regard. While generated JS code is maybe
> "good" enough to do debugging I would disagree that when u would
> decide to drop Haxe afterwards that the generated code is good enough
> that u would not feel the need to rewrite it so it is more
> maintanable. That is definetely true for cpp code of course. I do not
> know much about the other targets. I might be wrong, so anybody feel
> free to correct me on that.
>
I think going in with the concept you are likely to drop Haxe is
probably a bad idea anyway, your only likely to want to swap to a
similar alternative like inferior Typescript, in which case I think you
would just wrap stuff suitably and get on with the alternative.
Realistically there is no reason why you would move back apart from
internal politics, It seems more that you might want to move parts of a
system to Haxe and as it proves itself more and more. With Haxe you can
move at your own pace so really there is no risk.
I think if you turn this argument round you see that it makes no
sense... Why code something in Javascript and then have to rewrite it
properly in Haxe to get some real control and structure to your
project! Your taking a Javascript perspective or everyone else
perspective, but if you take a code perspective or your own company
perspective then Haxe makes more sense it's a much better way to code
the javascript in your project and it just takes a couple of hours of
experimenting to realize why, every time you find something f'up in the
browser you don't need a frame work to hide it you just abstract the
horrible bit away because you have a language that makes that easy.
companies they end up with a mish match of tech, with front end
developers using what ever takes thier fancy, I do wonder if time
investment with a powerful language like Haxe makes it more feasible to
create what you need in terms of components, interactions and structures
and minimize some of the crutches that developers bloat projects with.
For instance many of the frameworks that companies are currently
subscribing to in javascript are purely because Javascript is too sloopy
and allows code to become a mess and could be done with a few haxe
library toolkits instead.
> Haxe is still a bit of a niche: It might be a problem if u need some
> external help in form of freelancers for example. Good luck finding
> somebody who is profecient in Haxe. I for example do not know anybody
> personally.
>
There are some very able haxe freelancers to be found on the Haxe IRC
and in some of the library groups ( Kha, Openfl, Luxe etc... ) they are
unlikely to be local to you for obvious reasons, but I don't see that it
should be a problem to find someone more than profecient in Haxe and
sometimes also with great expertise in many of the languages Haxe
targets, since Haxe language often grows programmers field of knowledge,
since it creates stepping stones into other languages that are exciting
to take rather than daunting.
> Documentation can be lacking: While the language itself is nowadays
> very well documented it is not true for many libraries. I encountered
> that problem especially when I wanted to do some cpp stuff. Try to
> find some documentation on the cpp Pointer class for example. Or how
> hxcpp building works (which is important to understand if u want to
> integrate some c++ libs). Or somebody mentioned to "use kha".. yes, I
> would love too, but without documentation it is just to time consuming.
>
This can be true of well documented languages... often it's really hard
to find good useful information, for instance in experimenting with Haxe
swing I was often fustrated by many sources of information being rather
shallow and did not really provide the overview, but too often got
muddled by the Java's love of abstracting to the complex to obscure the
simple.
around code in a way that lets you loose sight of structuring classes
and easily you end up with classes that are too big. A simple IDE and
trace debugging forces you to try to break up code into managable
testable chunks. But I do agree tooling in Haxe could be improved, I
would just like to see the bases being vim, textmate etc.. rather than
java based IDE that are overly complex.
base so if your practical then this is only a purist argument. If your
targetting Mobile then you would use the C++ and possibly cppia for
testing, using Starling every day it drives me crazy that it's really so
unlike real flash, and touch events bugs when you don't use inheritance
everywhere - have driven me crazy, and feathers seem to fall off. I am
pretty sure NME haxe c++ is much closer to normal flash and with cppia
it's really fast to compile.
> That is also true if u just use a jar on the java target platform,
> btw. So u will need extern definitions again. At least this is my
> experience, somebdoy might correct me on this again, since I did just
> try it briefly without much investgating.
>
Some Jars work really well without doing anything, it's pretty amazing I
am unsure how many of the problem ones have been submitted, but it's
getting pretty easy these days I don't think if you choose carefully you
will need to many externs hand written, you may have to avoid one or two
large frameworks.
> So by mentioning all that I just want to help to paint a realistic
> picture. Not everything might be right, but this is my current
> perception. I am happy to be corrected if somebody feels like the
> critics are unjustified.
>
Well the critics are justified but I add my thoughs as possible counters
to them, I realize that some of my thoughs may not hold water with many
peoples approaches. But I do believe that some of the javascript
workflows that are currently popular are due to the mess of the
language, and would be laughed at if approach that way in a more
structured language. So the arguments are lessened in a more
structurely expressive language.
But would be really interesetd in any blog post you make covering some
of the workrounds and approaches you have discovered when using Haxe.
PS there are at least two very good libraries in Haxe that cover short
Lambda so it is not a biggy.
Best Justin
Just some thoughts that might have some truth...
On 30/11/2015 22:03, Atul Kumar wrote:
> while I also like haxe and would rather work with haxe code instead
> of, for example, js any day there are definetely some draw backs which
> should be mentioned. Like you said I also consider a list of trade
> offs very important for a presentation which suppose to present a
> realistic view in considering haxe as a technology stack.
>
> Since there are many pro arguments mentioned in this thread already
> let me step in and give you some trade offs to consider:
>
> Generated code is not 100% as u would write it yourself: Typescript
> does much better in that regard. While generated JS code is maybe
> "good" enough to do debugging I would disagree that when u would
> decide to drop Haxe afterwards that the generated code is good enough
> that u would not feel the need to rewrite it so it is more
> maintanable. That is definetely true for cpp code of course. I do not
> know much about the other targets. I might be wrong, so anybody feel
> free to correct me on that.
>
probably a bad idea anyway, your only likely to want to swap to a
similar alternative like inferior Typescript, in which case I think you
would just wrap stuff suitably and get on with the alternative.
Realistically there is no reason why you would move back apart from
internal politics, It seems more that you might want to move parts of a
system to Haxe and as it proves itself more and more. With Haxe you can
move at your own pace so really there is no risk.
I think if you turn this argument round you see that it makes no
sense... Why code something in Javascript and then have to rewrite it
properly in Haxe to get some real control and structure to your
project! Your taking a Javascript perspective or everyone else
perspective, but if you take a code perspective or your own company
perspective then Haxe makes more sense it's a much better way to code
the javascript in your project and it just takes a couple of hours of
experimenting to realize why, every time you find something f'up in the
browser you don't need a frame work to hide it you just abstract the
horrible bit away because you have a language that makes that easy.
> Using libraries of the native platform will require extern definition
> files: If u want to use a lot of js libs in your haxe code u will
> definietely need them. Otherwise there is no big advantage anymore to
> use haxe at all. If they are not available u have to get your hands
> dirty and write them yourself. While that is true for typescript as
> well chances are higher that somebody provides them already since
> adoption of typescript is higher. For cpp u will need some "glue" code
> in most cases I guess.
>
I see javascript coders just try to drop in components but for larger
> files: If u want to use a lot of js libs in your haxe code u will
> definietely need them. Otherwise there is no big advantage anymore to
> use haxe at all. If they are not available u have to get your hands
> dirty and write them yourself. While that is true for typescript as
> well chances are higher that somebody provides them already since
> adoption of typescript is higher. For cpp u will need some "glue" code
> in most cases I guess.
>
companies they end up with a mish match of tech, with front end
developers using what ever takes thier fancy, I do wonder if time
investment with a powerful language like Haxe makes it more feasible to
create what you need in terms of components, interactions and structures
and minimize some of the crutches that developers bloat projects with.
For instance many of the frameworks that companies are currently
subscribing to in javascript are purely because Javascript is too sloopy
and allows code to become a mess and could be done with a few haxe
library toolkits instead.
> Haxe is still a bit of a niche: It might be a problem if u need some
> external help in form of freelancers for example. Good luck finding
> somebody who is profecient in Haxe. I for example do not know anybody
> personally.
>
and in some of the library groups ( Kha, Openfl, Luxe etc... ) they are
unlikely to be local to you for obvious reasons, but I don't see that it
should be a problem to find someone more than profecient in Haxe and
sometimes also with great expertise in many of the languages Haxe
targets, since Haxe language often grows programmers field of knowledge,
since it creates stepping stones into other languages that are exciting
to take rather than daunting.
> Documentation can be lacking: While the language itself is nowadays
> very well documented it is not true for many libraries. I encountered
> that problem especially when I wanted to do some cpp stuff. Try to
> find some documentation on the cpp Pointer class for example. Or how
> hxcpp building works (which is important to understand if u want to
> integrate some c++ libs). Or somebody mentioned to "use kha".. yes, I
> would love too, but without documentation it is just to time consuming.
>
to find good useful information, for instance in experimenting with Haxe
swing I was often fustrated by many sources of information being rather
shallow and did not really provide the overview, but too often got
muddled by the Java's love of abstracting to the complex to obscure the
simple.
> Lack of tooling: IDE support could be better. On windows there is
> FlashDevelop, on mac ur choices are text editors like Sublime or Atom
> or IntelliJ. While Sublime (and surely Atom) are great for haxe, they
> are no real IDEs. There is no debugger or fancy refactoring. While
> Intellij suppose to fill that gap it still feels to rough for me. I
> always hit some brick wall when I want to use it. U can use a debugger
> on your generated code though, which works "so so" I would say.
>
I do agree but also power development does often result in jumping
> FlashDevelop, on mac ur choices are text editors like Sublime or Atom
> or IntelliJ. While Sublime (and surely Atom) are great for haxe, they
> are no real IDEs. There is no debugger or fancy refactoring. While
> Intellij suppose to fill that gap it still feels to rough for me. I
> always hit some brick wall when I want to use it. U can use a debugger
> on your generated code though, which works "so so" I would say.
>
around code in a way that lets you loose sight of structuring classes
and easily you end up with classes that are too big. A simple IDE and
trace debugging forces you to try to break up code into managable
testable chunks. But I do agree tooling in Haxe could be improved, I
would just like to see the bases being vim, textmate etc.. rather than
java based IDE that are overly complex.
>
> And also I want to leave a few words about OpenFL and targeting Flash:
> It is not that simple as it seems on first sight. Last time I checked
> OpenFL uses the native display list when targeting flash. So no
> Stage3D. That is on mobile in most cases a no go. U could just use the
> starling lib and use it in haxe, but also the last time I checked u
> have to patch it and u loose all arguments names of functions when u
> just use the swc for example (the Haxe Starling port seems very
> immature to me).
>
It's feasible to mix as3 swc's with Haxe using either as3 or Haxe as the
> And also I want to leave a few words about OpenFL and targeting Flash:
> It is not that simple as it seems on first sight. Last time I checked
> OpenFL uses the native display list when targeting flash. So no
> Stage3D. That is on mobile in most cases a no go. U could just use the
> starling lib and use it in haxe, but also the last time I checked u
> have to patch it and u loose all arguments names of functions when u
> just use the swc for example (the Haxe Starling port seems very
> immature to me).
>
base so if your practical then this is only a purist argument. If your
targetting Mobile then you would use the C++ and possibly cppia for
testing, using Starling every day it drives me crazy that it's really so
unlike real flash, and touch events bugs when you don't use inheritance
everywhere - have driven me crazy, and feathers seem to fall off. I am
pretty sure NME haxe c++ is much closer to normal flash and with cppia
it's really fast to compile.
> That is also true if u just use a jar on the java target platform,
> btw. So u will need extern definitions again. At least this is my
> experience, somebdoy might correct me on this again, since I did just
> try it briefly without much investgating.
>
am unsure how many of the problem ones have been submitted, but it's
getting pretty easy these days I don't think if you choose carefully you
will need to many externs hand written, you may have to avoid one or two
large frameworks.
> So by mentioning all that I just want to help to paint a realistic
> picture. Not everything might be right, but this is my current
> perception. I am happy to be corrected if somebody feels like the
> critics are unjustified.
>
to them, I realize that some of my thoughs may not hold water with many
peoples approaches. But I do believe that some of the javascript
workflows that are currently popular are due to the mess of the
language, and would be laughed at if approach that way in a more
structured language. So the arguments are lessened in a more
structurely expressive language.
But would be really interesetd in any blog post you make covering some
of the workrounds and approaches you have discovered when using Haxe.
PS there are at least two very good libraries in Haxe that cover short
Lambda so it is not a biggy.
Best Justin
Atul Kumar
Nov 30, 2015, 10:16:01 PM11/30/15
to Haxe
I was mainly referring to Peter Štefček presentation at https://www.youtube.com/watch?v=CupIdO-GpVg which somebody linked to. While being excellent he saying some things in the end like "u do not risk anything because u can always drop haxe and just use the generated sources", which I disagree with. And while I am not saying u r going in there thinking u will drop it 'likely' it is still something to consider. There could be reasons, if not now maybe later. What if the compiler will not be maintained in the future and bugs will not get fixed? What if maintaining externs gets to cumbersome? What if I work for customers who decides they need a javascript source base? There might come up things I can not foresee. Javascript will always work, since it is native to the browser.
I think if you turn this argument round you see that it makes no
sense... Why code something in Javascript and then have to rewrite it
properly in Haxe to get some real control and structure to your
project! Your taking a Javascript perspective or everyone else
perspective, but if you take a code perspective or your own company
perspective then Haxe makes more sense it's a much better way to code
the javascript in your project and it just takes a couple of hours of
experimenting to realize why, every time you find something f'up in the
browser you don't need a frame work to hide it you just abstract the
horrible bit away because you have a language that makes that easy.
"Real control" is actually an argument pro javascript. Since if u give a bit control away at all it is because of using haxe. Of course the pro argument for haxe in having structured code stands, but that is true for typescript as well.
If I would be a project manager desperately in need of a Freelancer I would feel much better if my project is written in js or typescript than in haxe at least ;)
I would disagree on that. I wonder If u ever worked heavily on a full bloated IDE yourself. I switch between Intellij and Sublime and can definitely appreciate both. But having complex features like "pull / push member", "auto implement methods" for interfaces, "extract method / variable", "move to package", etc. really helps me to write well structured code. Where in Sublime I sometimes think "do I really need to move this class to another package (and consequently start a 'find an replace in files')", in IntelliJ it is simply a drag n drop. But I had this discussion before and it is probably a question of preference. But in one thing I am sure: For many people it is a drawback not having good IDE support.
>
> And also I want to leave a few words about OpenFL and targeting Flash:
> It is not that simple as it seems on first sight. Last time I checked
> OpenFL uses the native display list when targeting flash. So no
> Stage3D. That is on mobile in most cases a no go. U could just use the
> starling lib and use it in haxe, but also the last time I checked u
> have to patch it and u loose all arguments names of functions when u
> just use the swc for example (the Haxe Starling port seems very
> immature to me).
>
It's feasible to mix as3 swc's with Haxe using either as3 or Haxe as the
base so if your practical then this is only a purist argument. If your
targetting Mobile then you would use the C++ and possibly cppia for
testing, using Starling every day it drives me crazy that it's really so
unlike real flash, and touch events bugs when you don't use inheritance
everywhere - have driven me crazy, and feathers seem to fall off. I am
pretty sure NME haxe c++ is much closer to normal flash and with cppia
it's really fast to compile.
Well.. u r the one who said "AIR the second most used approach for Android development is easily target when you compile Openfl to flash"
And I was referring to that, saying it is not that simple. I am saying that in that case u r loosing gpu acceleration. Ok, now your saying "If your targeting Mobile then you would use the C++.." but then u loose the AIR eco system again, so say goodbye to ANEs and StageVideo / VideoTexture support (for me the main reasons for sticking with AIR). You can not have both.
Don't get me wrong, I am not saying haxe and its frameworks r not providing great possibilities, I am just trying to be realistic and be careful of making false promises.I am just saying that claiming that u just drop in OpenFL and everything auto magically works everywhere is a bit of sugarcoating.
Philippe Elsass
Dec 1, 2015, 5:42:08 AM12/1/15
to Haxe
I think the argument that "you don't find Haxe devs" can be greatly played down: in my experience training someone in Haxe takes at most a pair of weeks.
They won't be macro experts but they can easily join a project and be a productive contributor. Any JS, Flash, Java, etc. developer can quickly jump in.
--
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/d/optout.
--
Philippe
Itzik Arzoni
Dec 1, 2015, 6:03:24 AM12/1/15
to Haxe
Thank you for the Pro vs Cons discussion. I will surly take these things into consideration. I just want to add that this is an introduction presentation for developers from all the disciplines who never heard of Haxe before.
I they will consider giving Haxe a second thought after it, than I could mention the balanced approach.
By the way, about training people there are two arguments: First, it would take longer to train a Haxe dev with no knowladge of JavaScript (like me) about JS, than to train a JS dev Haxe. Same thing if they try to go to solutions like OpenFl. Teaching OpenFl to someone who doesn't know Flash is Much Harder than teaching Haxe to a flash developer.
So the fact is, that Haxe is a tool that is much easier to teach when you know the field, and programming with Haxe is not an excuse for not knowing the field, If any - It just makes the learning curve Much easier! (I hope this makes sense...)
I'm planning to record my talk, but it would be in Hebrew, to overcome the.... Language barrier.
Reply all
Reply to author
Forward
0 new messages