> Look like ECMAScript2015 (JavaScript, or TypeScript) very much ...
The more Java like expressions is probably because the original author Nicolas
Cannasse wrote the MTASC ( Flash ) compiler. What used ActionScript and this in
turn turned into ECMAScript. Describing it like JavaScript is almost like a
insult _lol_. Got a profound dislike for JavaScript and can not say the same
for Haxe.
To me its more like a extended PHP 7.1 design. Then again, PHP has slowly been
merging towards a full C/Java style.
> Why that effort? See google or Manning page:
Contact them a few days ago and they updated the shipping address. So Krux02 is
going to ge the book directly.
> Apart from the fact that it forces this object oriented programming paradigm
> that I alread learned to dislike from Java, it seems to be designed pretty ok.
Personally i do not understand why people still insist on functional
programming. In general object oriented programming results in a more clean
code base ( example ).
* * *
class FloatTools {
static public function round(f:Float) {
return Math.round(f * 100) / 100; // The value 100 rounds to two
decimals
}
}
using FloatTools; // Adding 'FloatTools' as a static extension
class Main {
static function main() {
var f = 0.119999;
var rf = f.round(); // 0.12
var rf = 0.119999.round(); // 0.12
}
}
* * *
static function round(f) {
return Math.round(f * 100) / 100; // The value 100 rounds to two
decimals
}
include "round.xxx";
var f = 0.119999;
var rf = round(f); // 0.12
var rf = round(0.119999); // 0.12
* * *
Both do the same in this simple example. But as one starts to extend
functionality, its where you are much more likely to run into conflicts (
forcing the need for instance to namespace ). Of the two examples, what is more
easy to extend ( inherit, override, abstract, etc ) and clean. Its simply the
object oriented version. :)
The fact that it also forces the first initial call ( the Main construct ) to
be a class, is less of a issue ( unless losing 4 lines of code, of the 1000's
is a issue ;) ). If we simply look at GoLang with its forced function paradigm,
it still relies on C like function attachment to objects.
I said it before but coming from a PHP background and with the PHP7 / 7.1
designs, its more easy to get into Haxe then Nim.
Nim really focuses more to Python developers. Where Crystal really focused on
Ruby developers.
Nim & Haxe are languages that more incorporate from other languages. Crystal is
almost a copy of Ruby ( but they recently start to incorporate other
functionality from other languages ).
For me Haxe solves a few problems. Going to push it at work simply because: One
can code base it for PHP but at the same time deal with the annoying JS and
deal with Angular. Now at work its all separated and frankly messy ( but that
is a different topic ;) ).
Almost forgot, another useful corner for Nim to look at:
[http://code.haxe.org](http://forum.nim-lang.org///code.haxe.org)/
