You lost me at 'public static function main.'
Functions are public by default. You could leave that out. The main function has to be static and will serve as the entrance point of the program , not the class. So this might just look like too much when in fact this is just a very small code sample. Did I address some of your concerns, or did I miss the point entirely? Just curious.
Try Haxe
41–50 of 89 posts
Re: Try Haxe
#42You lost me at 'public static function main.'
Functions are public by default. You could leave that out. The main function has to be static and will serve as the entrance point of the program , not the class. So this might just look like too much when in fact this is just a very small code sample. Did I address some of your concerns, or did I miss the point entirely? Just curious.
"static function main()" seems to work as an entrance point, though, which makes sense somehow...
Re: Try Haxe
#43My initial gut reaction to Haxe from the homepage alone, was "Gah, this language is ugly!'. Then I immediately realized that this ugliness was from the fact that the Source example isn't using a monospaced font. It's sort of amazing that, at least for me, using a proportional font just makes things "look wrong", even though everything is syntactically correct.
Re: Try Haxe
#44Earlier quoted context omitted.
Functions are public by default. You could leave that out. The main function has to be static and will serve as the entrance point of the program , not the class. So this might just look like too much when in fact this is just a very small code sample. Did I address some of your concerns, or did I miss the point entirely? Just curious.
Actually functions are private by default. "static function main()" seems to work as an entrance point, though, which makes sense somehow...
Re: Try Haxe
#45Earlier quoted context omitted.
Functions are public by default. You could leave that out. The main function has to be static and will serve as the entrance point of the program , not the class. So this might just look like too much when in fact this is just a very small code sample. Did I address some of your concerns, or did I miss the point entirely? Just curious.
I think his comment could be refrased as "This language looks like Java"
Re: Try Haxe
#46Earlier quoted context omitted.
Functions are public by default. You could leave that out. The main function has to be static and will serve as the entrance point of the program , not the class. So this might just look like too much when in fact this is just a very small code sample. Did I address some of your concerns, or did I miss the point entirely? Just curious.
I think his comment could be refrased as "This language looks like Java"
Re: Try Haxe
#47demos : Flash API to SWF or JS (nme/jeash): http://try.haxe.org/#655c1 http://try.haxe.org/#E4001 Flash with custom shaders (hxsl): http://try.haxe.org/#93bE1 Flash + away3d: http://try.haxe.org/#9F075
Re: Try Haxe
#48Haxe sounds too good to be true. Why would anyone use any of the other game engines out there which are targeted towards the mobile world if they could use Haxe? I see many half-donejavascript frameworks and fully-baked lua frameworks...what do they provide that Haxe doesn't? Can anyone who has done significant Haxe work comment to some of the benefits and drawbacks? I ask as someone in search of a gaming engine whic…
Haxe isn't a game engine. It's a language that compiles into other languages.
Re: Try Haxe
#49Haxe sounds too good to be true. Why would anyone use any of the other game engines out there which are targeted towards the mobile world if they could use Haxe? I see many half-donejavascript frameworks and fully-baked lua frameworks...what do they provide that Haxe doesn't? Can anyone who has done significant Haxe work comment to some of the benefits and drawbacks? I ask as someone in search of a gaming engine whic…
The Haxe language gives you far more flexibility and performance optimizations, since it is generating optimized native source or byte code. The cost is that you have to learn the Haxe language.
Many people on this discussion are criticizing the java-style syntax of Haxe. I think most of these negative feelings are due to the excessive boilerplate required for many Java classes. Haxe does away with a lot of boilerplate code using type inference and other modern compiler techniques. http://haxe.org/ref/type_infer
You can remove even more boilerplate with macro libraries for shorthand class declarations: https://github.com/back2dos/tinkerbell/wiki/tink_lang
There are many other tricks you can use to define behavior without resorting to complex inheritance or class definitions. One of my favorites is the "using" declaration: http://haxe.org/manual/using
So, in my opinion, the cost of learning Haxe is very low if you already know Java or Actionscript. The cost of coding/writing Haxe is also very low, since you're not required to write boilerplate code.
Finally, it's worth mentioning that the Haxe developers are not just trying to gloss over the technicalities of each underlying platform in order to get things working. They really understand the behavior of each platform, and make many conscientious decisions based on considerations for performance and cross-platform consistency. I've learned more from the Haxe language google group about each target (js quirks, java limitations, etc.) than I have from the Java, JS, Actionscript groups themselves: https://groups.google.com/forum/#!forum/haxelang Many people have remarked that simply following the Haxe development list has made them a better programmer.
Re: Try Haxe
#50My initial gut reaction to Haxe from the homepage alone, was "Gah, this language is ugly!'. Then I immediately realized that this ugliness was from the fact that the Source example isn't using a monospaced font. It's sort of amazing that, at least for me, using a proportional font just makes things "look wrong", even though everything is syntactically correct.
Also in the current color scheme, the preprocessor directives are dark red against a dark blue background. Not exactly pleasing.