top 50 comments

sorted by: hot top controversial new old
[–] 138 points 2 years ago (12 children)

On the other hand, I don't think you should add those ever

  • source
  • hideshow 12 child comments
  • [–] 52 points 2 years ago (7 children)

    Sure. But in a sane language doing something totally nonsensical like that is an error, and in a statically typed language it’s a compiler error. It doesn’t just silently do weird shit.

  • source
  • parent
  • hideshow 7 child comments
  • load more comments (4 replies)
  • [–] 46 points 2 years ago (3 children)

    Onfuscators probably use it though, so no spec ever will be able to get rid of this crap.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 119 points 2 years ago* (last edited 2 years ago) (29 children)

    Use TypeScript, and nonsensical things like adding arrays to objects will be compile-time errors.

  • source
  • hideshow 29 child comments
  • [–] 58 points 2 years ago* (25 children)

    Yup. The libraries underneath will still allow nonsense at runtime, though, and it will now be harder to see, so it's a partial solution as done in standard practice.

    An all-TypeScript stack, if you could pull it off, would be the way to go.

  • source
  • parent
  • hideshow 25 child comments
  • [–] 22 points 2 years ago (2 children)

    Most libraries have TypeScript types these days, either bundled directly with the library (common with newer libraries), or as part of the DefinitelyTyped project.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 20 points 2 years ago (19 children)

    So a strictly typed language.. I think those already exist.

  • source
  • parent
  • hideshow 19 child comments
  • [–] 7 points 2 years ago (16 children)

    If there was an easy way to use rust or something on webassemly and use that instead of JS. I'd be so happy, but I can't find how to do it without npm.

  • source
  • parent
  • hideshow 16 child comments
  • load more comments (4 replies)
  • load more comments (2 replies)
  • load more comments (2 replies)
  • [–] 10 points 2 years ago (2 children)

    By that logic what we really need is a modernization of Ada, where there are no compiler warnings and anything that would generate one in another language is instead a compiler error, everything is strongly typed, etc, etc.

    If you aren't familiar with Ada, just imagine Pascal went to military school.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 5 points 2 years ago (1 child)

    Pascal went to military school.

    I'm not in love with the idea, but a language that cuts out the BS has a sudden appeal when on a group/team project.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 10 points 2 years ago

    That analogy was chosen for a reason. Ada was originally developed by DOD committee and a French programming team to be a programming language for Defense projects between 1977 and 1983 that they were still using at least into the early 2000s. It's based on Pascal.

    It was intended for applications where reliability was the highest priority (above things like performance or ease of use) and one of the consequences of that is that there are no warnings - only compiler errors, and a lot of common bad practices that will be allowed to fly or maybe at worst generate a warning in other languages will themselves generate compiler errors. Do it right or don't bother trying. No implicit typecasting, even something like 1 + 0.5 where it's obvious what is intended is a compiler error because you are trying to add an integer to a real without explicitly converting either - you're in extremely strongly-typed country here.

    Libraries are split across two files, one is essentially the interfaces for the library and the other is it's implementation (not that weird, and not that different than C/C++ header files though the code looks closer to Pascal interface and implementation sections put in separate files). The intent at the time being that different teams or different subcontractors might be building each module and by establishing a fixed interface up front and spelling out in great detail in documentation what each piece of that interface is supposed to do the actual implementation could be done separately and hypothetically have a predictable result.

  • source
  • parent
  • [–] 97 points 2 years ago (4 children)
  • load more comments (1 reply)
    [–] 40 points 2 years ago (1 child)

    Just wait until OP learns about cross product of matrices.

  • source
  • hideshow 1 child comment
  • [–] 39 points 2 years ago* (5 children)

    In node, I get the same result in both cases. "[object Object]"

    It's calling the toString() method on both of them, which in the array case is the same as calling .join(",") on the array. For an empty array, that results in an empty string added to "[object Object]" at either end in the respective case in the picture.

    Not sure how we'd get 0 though. Anybody know an implementation that does that? Browsers do that maybe? Which way is spec compliant? Number([]) is 0, and I think maybe it's in the spec that the algorithm for type coercion includes an initial attempt to convert to Number before falling back to toString()? I dunno, this is all off the top of my head.

  • source
  • hideshow 5 child comments
  • [–] 44 points 2 years ago* (4 children)

    The inspector REPL evaluates as a statement-with-value (like eval), so the {} at the beginning is considered an empty block, not an object. This leaves +[], which is 0. I don't know what would make Node differ, however.

    Edit: Tested it myself. It seems Node prefers evaluating this as an expression when it can, but explicitly using eval gives the inspector behavior:

  • source
  • parent
  • hideshow 4 child comments
  • [–] 21 points 2 years ago (3 children)

    So there's yet another level of quirkery to this bullshit then, it seems. 😆 Nice digging! 🤝

    I also noticed that if you surround the curlies with parentheses, you get the same again:

    > eval('{} + []')
    0
    > eval('({}) + []')
    '[object Object]'
    
  • source
  • parent
  • hideshow 3 child comments
  • [–] 25 points 2 years ago (2 children)

    This is why I try my damnedest not to write in weakly typed languages.

    string + object makes no logical sense, but the language will be like "'no biggie, you probably meant string + string so let's convert the object to string"! And so all hell breaks loose when the language's assumption is wrong.

  • source
  • hideshow 2 child comments
  • load more comments (1 reply)
    [–] 21 points 2 years ago (1 child)
  • [–] 20 points 2 years ago* (3 children)

    It's best not to touch anything web related, lest you want to go mad. It's like the elder scrolls or laying eyes on some cosmic horror creature. Tbf this also goes for C++

  • source
  • hideshow 3 child comments
  • load more comments (3 replies)
    [–] 19 points 2 years ago* (5 children)

    Who would use that kind of type coercion? Who? I want to see his face.

  • source
  • hideshow 5 child comments
  • [–] 12 points 2 years ago (3 children)

    I take this as less of a "I can't use this intuitive feature reliably" thing and more of a "the truth table will bite you in the ass when you least expect it and/or make a mistake" thing.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 15 points 2 years ago* (1 child)
    {} + 0
    >> 0
    
    0 + {}
    >> "0[object Object]"
    

    I'm going home.

  • source
  • hideshow 1 child comment
  • load more comments (1 reply)
    [–] 15 points 2 years ago (8 children)
  • [–] 25 points 2 years ago (7 children)

    I've read different defenses for JavaScript for cases like this, which usually runs somewhere from you shouldn't be doing that anyway all the way up to if you just understood the language better you'd know why. While I agree with both of those points strongly as general principles, JavaScript also violates the principle of least surprise enough to make it concerning.

    For what it's worth, I do like JavaScript. I really don't think that there is any perfect programming language.

  • source
  • parent
  • hideshow 7 child comments
  • [–] 8 points 2 years ago (1 child)

    JavaScript, like some other languages of the time, was designed with the Robustness Principle in mind. Arguably the wrong end of the Robustness Principle, but still.

    That is, it was designed to accept anything that wasn't a syntax error (if not a few other things besides) and not generate run-time errors unless absolutely necessary. The thinking was that the last thing the user of something written in JavaScript wants is for their browser to crash or lock up because something divided by zero or couldn't find an object property.

    Also it was originally written in about five minutes by one guy who hadn't had enough sleep. (I may have misremembered this part, but I get the feeling I'm not too far off.)

  • source
  • parent
  • hideshow 1 child comment
  • [+] 14 points 2 years ago
    [removed by mod]
  • source
  • [–] 8 points 2 years ago

    I love inside jokes. I hope you be apart of one someday

  • source
  • [–] 7 points 2 years ago*

    How about SQL in PostgreSql? query: select array_length(Array[]::text[], 1) Output: null

    Dont get me wrong JS is still awful

  • source
  • [–] 4 points 2 years ago

    Just be better lmao

  • source
  • load more comments
    view more: next ›