HaXe



  • Been learning HaXe on my free time, since it looks so promising for multiplatform development and also all the cool kids are doing it[citation needed].

    Besides, it has a familiar ECMAScript-like syntax which I like.

    But the language has its warts. Including some... surprising ones.

    Me:

    <font color="#999999">126</font>        this.left   = ( config == null || config.  left == null ) ?    -0.5  : config.  left;
    <font color="#999999">127</font>        this.right  = ( config == null || config. right == null ) ?    +0.5  : config. right;
    <font color="#999999">128</font>        this.top    = ( config == null || config.   top == null ) ?    +0.5  : config.   top;
    <font color="#999999">129</font>        this.bottom = ( config == null || config.bottom == null ) ?    -0.5  : config.bottom;
    <font color="#999999">130</font>        this.near   = ( config == null || config.  near == null ) ?    +0.01 : config.  near;
    <font color="#999999">131</font>        this.far    = ( config == null || config.   far == null ) ? +1000.0  : config.   far;
    
    HaXe compiler:
    Source/Camera.hx:126: characters 51-55 : Unexpected left
    Source/Camera.hx:126: characters 59-63 : Missing ;
    Source/Camera.hx:126: characters 64-65 : Unexpected )
    

    Me, after learning you can't have spaces after the period preceding a property name, for some reason:

    <font color="#999999">126</font>        this.left   = ( config == null || config.left   == null ) ?    -0.5  : config.left  ;
    <font color="#999999">127</font>        this.right  = ( config == null || config.right  == null ) ?    +0.5  : config.right ;
    <font color="#999999">128</font>        this.top    = ( config == null || config.top    == null ) ?    +0.5  : config.top   ;
    <font color="#999999">129</font>        this.bottom = ( config == null || config.bottom == null ) ?    -0.5  : config.bottom;
    <font color="#999999">130</font>        this.near   = ( config == null || config.near   == null ) ?    +0.01 : config.near  ;
    <font color="#999999">131</font>        this.far    = ( config == null || config.far    == null ) ? +1000.0  : config.far   ;
    
    HaXe compiler:
    Source/Camera.hx:127: characters 68-69 : Unexpected +
    Source/Camera.hx:127: characters 68-69 : Unexpected +
    

    Me:

    Seriously??

    And that wasn't a copy-paste error. It complained twice about the first plus sign.



  • @Zecc said:

    this.left = (config == null || config.left == null) ? -0.5 : config.left;

    I like

      this.left = config && config.left || -0.5;
    

    It's concise, and after seeing this more than once you get used to it quite quickly - it's also very useful when chaining conditions.

    As for your WTF: Why HaXe, and not one of the more mature products, e.g. PhoneGap?



  • @configurator said:

    I like

      this.left = config && config.left || -0.5;
    

    Are you sure it works even if config.left is equal to 0 ?



  • You code makes baby Jesus cry.

    The + thing being a syntax error is shit though. If they're using ECMAScript, why don't they use V8? Or some other JS engine that's already 50,000 times better than theirs will ever be?



  • @Planar said:

    @configurator said:
    I like

      this.left = config && config.left || -0.5;
    

    Are you sure it works even if config.left is equal to 0 ?

    It doesn't - it would set left to -0.5 rather than 0. Except for function settings, I rarely have default values other than zeroes or empty strings, so I didn't think of that. Also, I'm a little rusty, I haven't used ECMAScript in months. Not that that's a good excuse.



  • @blakeyrat said:

    why don't they use V8? Or some other JS engine

    Probably because they compile their JS into other languages rather than running it in any engine.



  • @configurator said:

    I like

      this.left = config && config.left || -0.5;

     

    Why the heck doesn't this evaluate to simply "true" ?

     



  • @configurator said:

    @blakeyrat said:
    why don't they use V8? Or some other JS engine

    Probably because they compile their JS into other languages rather than running it in any engine.

    Ok, then why don't they use the bits of V8 that do things well that their own code seems to suck shit at? I don't know why you bothered to post a reply to my question if you weren't actually going to reply to my question.



  • @blakeyrat said:

    The + thing being a syntax error is shit though.
    Why? There can't be too many languages with a unary 'plus' operator, if only because it's entirely useless.

     


  • Discourse touched me in a no-no place

    @Severity One said:

    Why? There can't be too many languages with a unary 'plus' operator, if only because it's entirely useless.
    Not true in languages where expressions don't have a fixed result type. Such as javascript, or python, perl, ruby, tcl, …

    You don't need it very often though.



  • @blakeyrat said:

    @configurator said:
    @blakeyrat said:
    why don't they use V8? Or some other JS engine

    Probably because they compile their JS into other languages rather than running it in any engine.

    Ok, then why don't they use the bits of V8 that do things well that their own code seems to suck shit at? I don't know why you bothered to post a reply to my question if you weren't actually going to reply to my question.

    The point of HaXe is to translate or compile HaXe code into other languages, and javascript is one of the targets. V8 is good as parsing javascript, I suppose. That doesn't mean it would be suitable for parsing HaXe. Because I can guarantee you that V8 is shit at parsing HaXe. And then once it has parsed the code, what do you do with it? You don't directly run HaXe code. You pass it to another compiler or interpreter.

    So, once again, the problem wasn't that he didn't reply to your question, but that you don't know enough about the topic to discuss it intelligently. And even when people bring up good points, you dismiss them because you don't understand them.

    They've made some odd choices about how they parse HaXe, and one has to wonder if they were deliberate decisions or implementation WTFs.



  • @topspin said:

    @configurator said:

    I like

      this.left = config && config.left || -0.5;

     

    Why the heck doesn't this evaluate to simply "true" ?

     

     

    Because there are many versions of truth... and when you shortcut the evaluation, it makes sense to return the exact one that caused you to do so.

    I quite like that part of JS, Honest Truthiness...

     



  • @configurator said:

    I like

      this.left = config && config.left || -0.5;
    

    So do I. Buuuut...

    @HaXe compiler said:
    Source/Camera.hx:126: characters 22-43 : OrthoCameraConfig should be Bool
    Source/Camera.hx:126: characters 22-43 : { ?top : Null<Float>, ?side : Null<Array<Float>>, ?right : Null<Float>, ?position : Null<Array<Float>>, ?near : Null<Float>, ?left : Null<Float>, ?far : Null<Float>, eye : Array<Float>, ?bottom : Null<Float> } should be Bool
    Source/Camera.hx:126: characters 22-43 : Null<Float> should be Bool
    Source/Camera.hx:126: characters 22-43 : Float should be Bool
    Source/Camera.hx:126: characters 22-51 : Float should be Bool
    Source/Camera.hx:126: characters 8-51 : Bool should be Float
    Which renders the rest of the discussion mute as far as HaXe is concerned.

     

    @configurator said:

    As for your WTF: Why HaXe, and not one of the more mature products, e.g. PhoneGap?
    I'm trying to simultaneously learn the AS3 API. Just because. Same reason why I'm writing my own camera and scene graph classes too, I guess.

     



  • @Zecc said:

    Which renders the rest of the discussion mutemoot as far as HaXe is concerned.

    Aaaarghhhh



  • @boomzilla said:

    @Zecc said:
    Which renders the rest of the discussion mutemoot as far as HaXe is concerned.

    Aaaarghhhh

     

    OMG HAX



  • @Zecc said:

    Which renders the rest of the discussion mute as far as HaXe is concerned.

    "A 'moo point'?" "Yeah. It's like a cow's opinion: it doesn't matter. It's moo."

    ^- only good joke from Friends

    @Zecc said:

    I'm trying to simultaneously learn the AS3 API.

    The AS3 API takes like 20 seconds to learn. The shitty-ass IDEs you have to use to cope with it, however, it takes years to understand what new and interesting bugs they possess.

    @Zecc said:

    Same reason why I'm writing my own camera and scene graph classes too, I guess.

    You like wasting your time by building a buggier version of something that already exists?



  • @blakeyrat said:

    You like wasting your time by building a buggier version of something that already exists?
     

    How else will you learn anything?



  • @dhromed said:

    @blakeyrat said:
    You like wasting your time by building a buggier version of something that already exists?

    How else will you learn anything?

    Lots of profanity and pony references with caps lock on?



  • @boomzilla said:

    @dhromed said:
    @blakeyrat said:
    You like wasting your time by building a buggier version of something that already exists?

    How else will you learn anything?

    Lots of profanity and pony references with caps lock on?




    FUCK, ANYPONY CAN DO THAT.



  • @boomzilla said:

    @Zecc said:
    Which renders the rest of the discussion mutemoot as far as HaXe is concerned.

    Aaaarghhhh

    English isn't my native language, give me a brake!

    @blakeyrat said:

    You like wasting your time by building a buggier version of something that already exists?
    Yes.



  • @boomzilla said:

    @dhromed said:
    How else will you learn anything?

    Lots of profanity and pony references with caps lock on?

     

    Okay, so there are multiple paths.



  • @Zecc said:

    @boomzilla said:
    @Zecc said:
    Which renders the rest of the discussion mutemoot as far as HaXe is concerned.

    Aaaarghhhh

    English isn't my native language, give me a brake!

    Two shay!



  • Why do we need HaXe? Can't "HTML5" run everywhere yet?



  • @Severity One said:

    @blakeyrat said:

    The + thing being a syntax error is shit though.
    Why? There can't be too many languages with a unary 'plus' operator, if only because it's entirely useless.

     


    +myString is a nice shorthand for parseFloat(myString)



  • @blakeyrat said:

    You like wasting your time by building a buggier version of something that already exists?

    VALVE CALLS OFF HALF-LIFE 3; BLAMES PREEXISTENCE OF GUNS AND SINGLE-DIGIT INTEGERS



  • @Ben L. said:

    +myString is a nice shorthand for parseFloat(myString)

    That's right, weak typing has to go away first before unary plus.



  • @MiffTheFox said:

    @Ben L. said:
    +myString is a nice shorthand for parseFloat(myString)

    That's right, weak typing has to go away first before unary plus.

    But... But how will the internet cope without browsers putting up with all their bullshit?



  • @boomzilla said:

    @Zecc said:
    @boomzilla said:
    @Zecc said:
    Which renders the rest of the discussion mutemoot as far as HaXe is concerned.

    Aaaarghhhh

    English isn't my native language, give me a brake!

    Two shay!

    Their aaaargh to Manny WTF's two no hear.



  • @MiffTheFox said:

    Why do we need HaXe?
    Perhaps because HTML5 is useless in case the programmer gets hungry?



  • @Severity One said:

    @blakeyrat said:

    The + thing being a syntax error is shit though.
    Why? There can't be too many languages with a unary 'plus' operator, if only because it's entirely useless.

    Perl has a no-op unary + that's used to help out the parser; it indicates "this is meant to be an expression". (Perl syntax is kind-of ambiguous, so the interpreter sometimes needs hints.)

    For instance, $dict{shift} can be disambiguated as "return the element with key 'shift' from %dict", which is written as $dict{'shift'}, or "return the element whose key is the next function argument from %dict", which is written as $dict{+shift}; that's a unary +, and it's the easiest way to help the parser out here (because the 'shift' interpretation seems to be the default).

    (For what it's worth, having an actually ambiguous grammar for a language, and rules for disambiguation that can only be determined by experiment, seems to be more trouble than it's worth.)

     



  • @ais523 said:

    (For what it's worth, having an actually ambiguous grammar for a language, and rules for disambiguation that can only be determined by experiment, seems to be more trouble than it's worth.)

    Sometimes the DWIM engine can get confused. I've been a full-time perl programmer for several months now and I like a lot of its weirdnesses my workmates don't. They seem to hate map, postfix if/for/etc, bareword strings (like the left side of "=>"), omitting brackets and $_. I even had a cause to use "my @vals = @tmp{qw/a b c/};" which they cringed at, preferring "my @vals = ($tmp{'a'}, $tmp{'b'}, $tmp{'c'})". Oh well.

    @ais523 said:

    "return the element whose key is the next function argument from %dict", which is written as $dict{+shift}; that's a unary +, and it's the easiest way to help the parser out here (because the 'shift' interpretation seems to be the default).

    Barewords are quoted inside hash {}. And shift works on @_ by default, not necessarily "function arguments". "my $tmp = shift; $dict{$tmp}" would be equivalent to "$dict{+shift}", albeit with the temporary variable.



  • The reason $dict{shift} is ambiguous is that "shift" is a keyword, not just a bareword. (And if @_ doesn't contain your function arguments, you have more problems than just ambiguous syntax, because that's where the language puts them.)

    I've never needed to slice a hash like in the example you give above, but if I did, I'd definitely do it your way rather than your coworkers' way; that syntax exists for a reason.



  • You realize all this nonsense isn't exactly endearing me to Perl?



  • @blakeyrat said:

    You like wasting your time by building a buggier version of something that already exists?
    Isn't that how HaXe came to exist?



  • @ais523 said:

    The reason $dict{shift} is ambiguous is that "shift" is a keyword, not just a bareword.

    You'd have the same problem with a lot of keywords and functions. PHP has deprecated this behaviour for this reason.

    @ais523 said:

    And if @_ doesn't contain your function arguments

    You can assign to @_ and shift will happily work on that. Of the top of my head, though, it's not as magical as $_.

    Some of my perl might be a little confusing to perl novices but it makes sense to those comfortable with the paradigm. I first used perl in 1999 but only recently at a "perl shop", previously using it for quick and dirty scripts.



  • @Zemm said:

    I even had a cause to use "my @vals = @tmp{qw/a b c/};" which they cringed at, preferring "my @vals = ($tmp{'a'}, $tmp{'b'}, $tmp{'c'})".

    You can DO that? Perl is SO much more awesome now...



  • @dhromed said:

    You realize all this nonsense isn't exactly endearing me to Perl?
    Perl can be quite endearing, but it helps if you're into whips, gag balls, face masks, that sort of thing.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.