611
It was best as a silly toy language in the 1990's... (reddthat.com)
submitted 8 months ago by to c/programmer_humor@programming.dev
163 comments fedilink hide all child comments
 
you are viewing a single comment's thread
view the rest of the comments
[–] 2 points 8 months ago (1 child)

Operator overloading is a perfectly reasonable feature in a language to make use of and to assume works. If it is not going to behave sensibly, it should be an error, not nonsense, because having it work for strings but not other sequence types is surprising, and surprising is bad.

As I said, the fact that you didn't know the result means that JavaScript's type system is opaque and hard to understand. You might have understood that there are some things you "shouldn't do" but being hard to understand is a bad aspect of a language even if it doesn't prevent you from writing correct, good code.

By way of analogy, thing of a language which, like JavaScript, doesn't require semicolons, but they are accepted. Except, if you use a semicolon after the last statement in a block, that statement never gets executed. Your reply is like saying, "just don't use semicolons - they're not needed" instead of acknowledging that an element of the language which is prone to causing mistakes is bad design.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 8 months ago (1 child)

    I mean how can you define a sensible way to subtract Infinity from an array, or add an object to a string? The way JavaScript defines it is predictable, easy to compute, and handles bad code gracefully, which is a good tradeoff between doing something like matrix arithmetic on a CPU and just straight up crashing. If you’re doing silly things like that, you should know how JavaScript coerces types, but I don’t do silly things like that, so I don’t really care how JavaScript would handle it. Every language will do silly things if you force it to. That doesn’t make it a bad language.

    Do you feel the same about C because C lets you take pointers of pointers of pointers until you’re addressing random memory in an unpredictable way? No, because it’s silly to do that.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 3 points 8 months ago (1 child)

    I mean how can you define a sensible way to subtract Infinity from an array, or add an object to a string?

    TypeError.

    There are also various sensible ways, for example if you have an array of floats, subtracting Infinity from the array could result in an array of the same length as the original, with each value being negative Infinity. But in general inhomogeneous types should not be addable without careful thought to create a type system which is consistent and coherent. That is exactly what JavaScript did not do.

    It doesn't "handle bad code gracefully"; it handles it in a way that's hard to reason about and hence hard to work with.

    The way JavaScript defines it is predictable

    You literally just failed to predict it, so I don't think there's any point continuing this conversation.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 8 months ago* (2 children)

    Ok, except I did predict it. It turns them both into strings and gives you “12”. I checked it. But I didn’t mean predictable as in, you inherently know what it’s going to do, I meant predictable as in, it will follow the same basic rules in each circumstance.

    So, should web pages be prone to crashing if everything isn’t perfect? I don’t know if you remember XHTML, but that was basically what happened with that. You have a “div” within a “p”? Page crashed. You have an unclosed “span”? Page crashed. XHTML was abandoned because is constantly broke the web.

    Web technologies are supposed to be resilient, so throwing TypeError is the last resort for something that absolutely cannot work, like trying to add to a Symbol. Since nothing from the user is ever a Symbol (there’s no input that can give it, and it can’t be stored in JSON), it’s acceptable to throw a TypeError there.

    JavaScript is meant to be fast and resilient. Its type conversions make sense when you consider those goals.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 2 points 8 months ago (1 child)

    Ok, except I did predict it. It turns them both into strings and gives you “12”. I checked it.

    I would assume [1] + [2] would give you either 0 or 2, but maybe "12".

    I can totally predict the future like that. Tomorrow it might rain, it might not, or it might snow. Want me to predict your future for a small donation? Here's a small teaser: tomorrow you might or might not eat breakfast.

    My mystical powers lay the creation bare before me, all is predictable!

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 8 months ago

    Here’s my thought process: plus is for numbers and strings, so it’s gonna convert the arrays to either numbers or strings. If it converts them to 0, the answer is 0, if it converts them to 1, the answer is 2, if it converts them to strings, the answer is “12”.

    You know what I didn’t say? [1,2]. Because plus is not for array concatenation. The question is meant to make you think you’ll get [1,2], because why else would you use plus on arrays?

    In a language that uses plus for concatenation, you’ll see that kind of code all over, and know what you’ll get. But you never see that in JavaScript, because that’s not how we concatenate arrays.

  • permalink
  • fedilink
  • source
  • parent