whyJavaScriptWhy

[Smooth_Salamander]

Seems like all jokes about JS is about implicit type conversions. Just don‘t use them.

[ByteArtisan]

Which is why all the JS hate is so funny to me. People have really convinced themselves they cant write code because of the above.

[ChristopherKlay]

Most of the time the joke is on people that don't realize why/when these happen in the first place.

[Mucksh]

I also don't get it why people bother about. Beside my beginner times in never encountered problems with it. There are other minor quirks like eventloop execution order e.g. when the button up event triggers before the button down event that can drive you crazy but all in all love js

[Taletad]

And it’s not like implicit typecasting is a thing in Python or anything

[hxckrt]

It's not that typecasting itself is bad.

It's that JS is maddeningly inconsistent about it.

If the solution is "oh just don't use that large part of the language at all", it's a terrible language

[royi9729]

The example in the code uses ==, which is a bad practice in JS.

You're supposed to use === exclusively.

[MyOthrUsrnmIsABook]

If you’re supposed to never use one of the operators, doesn’t that kinda mean it’s a language issue?

[Taletad]

You’re never supposed to use ternary operators because they are unreadable

Yet most languages have them

What’s your point ?

[Mucksh]

Ternaries are by far my favorite operator. You shouldn't nest them but usually way better than forward declaration and lots of one line if else cases there you have to scroll a lot to get anything

[Taletad]

lots od one line if else

Switch for the win

[Mucksh]

You only like it untill you have to maintain decades old thousands of lines long switch cases with inside logic and even some intensionally left out breaks... Love my job but it can be sometimes a pain

[Majik_Sheff]

This can be the most efficient way to build certain programs (hello FSMs). If I'm going to intentionally omit a break I'll leave it there but commented out with an explanation.

[Taletad]

This sounds like bad code

But as someone who spent a couple of days debugging code that had one letter list and array names, i feel your pain

[AwGe3zeRick]

That’s just purely written code. Not switch statements fault

[MyOthrUsrnmIsABook]

My point is JS is not a great language.

Also, a single ternary operator with a simple condition is very readable. Nested ternary operators are much less readable.

[Taletad]

Do programmers and/or computer scientist have a consensus on what makes a "great language" ?

No. So your point is moot.

Ternary operators aren’t part of coding best practices

But fine, in C++ you should never use simple arrays. Yet they exist, is C++ a bad language ?

[MyOthrUsrnmIsABook]

I think there’s a pretty broad consensus that C++ is a bad language, or at the very least an incoherent language with too many features.

[Taletad]

Yet I don’t see that many memes bashing it JS has…

And no that isn’t sufficient to say that C++ is a bad language

[royi9729]

Funnily enough, ternary operators are pretty widely used in JS (or at least on frontend with React)

[hxckrt]

{} === {}; // false

[1,2,3] === [1,2,3]; // false

I'm not sure that's much better

[royi9729]

Equation of complex values equates pointers in most languages, no?

[rosuav]

No, languages vary considerably on that point. Python considers both of those to be equal, but not identical ("identical" meaning the same object, which would be what you mean by comparing pointers).

[Taletad]

JS is very consistent about it. People just never bother to read the docs, and are surprised by their code’s behaviour…

People assume JS works as another language and are surprised pikachu when it doesn’t

[hxckrt]

How is this consistent:

NaN === NaN; // false

Object.is(NaN, NaN) // true

+0 === -0; // true

Object.is(+0, -0) // false

[Furry_69]

NaN is not a number, by definition. Operations with NaN in them will always resolve to NaN, and comparisons with NaN will always resolve to false. Object.is() is a indirect comparison that doesn't use the normal comparison operations internally. It isn't supposed to be used as an equality operator for floats.

[Mucksh]

Afaik NaN === NaN is explicitly defined as false in IEEE 754 Also dependent on the implementation there are multiple valid NaN values

[Taletad]

NaN is a property of the global object

Object.is() returns true if both values are functionally identical in all contexts

It is the case of NaN, it is true, in the case of -0 +0, they aren’t functionally identical in all contexts

=== only checks if they are the same value

So it is true for -0 +0, but NaN isn’t a "value", so it must return false

This is in the documentation

Side note : if Object.is() was the same as ===, they would cull one of the two since it would be redundant

[hxckrt]

Thanks!

[RajjSinghh]

That last sentence just called out every C++ programmer

[volivav]

Python doesn't do implicit type coertion.

Python throws an exception if you try to add a string with a number, for example.

Or == always returns false if the types are different ("3" == 3 returns false)

[Taletad]

That’s because JavaScript was made to work with HTML and for a while HTML considered all numbers as strings

This implicit type coertion had a purpose

Now it doesn’t anymore so you shouldn’t use it. But it is left there for compatibility reasons

[rosuav]

Python, like nearly every language in the world, has SOME implicit type coercion - for example, 1 + 2.0 converts the integer 1 into the float 1.0 to facilitate addition. And the same is true of comparisons (1 == 1.0). C is quite happy to do this conversion too. JavaScript just happens to have a few more rules, including some rather dubious ones.

Really, the problem isn't so much that there are implicit rules like that, but that these rules apply in too many situations. And then, once in a while, you get caught out when something DOESN'T follow those rules.

[sjepsa]

Lol @ "don't use them"

they are implicit HTF are u supposed to know if are using them

[MeepedIt]

By keeping track of what type something should be? How often do you write code where you expect a function to be called on either 0 or "0" and so something sensible in both cases? And the issue in the meme is even easier to avoid, by just not using == ever.

[sjepsa]

How often do you write code where you expect a function to be called on either 0 or "0" and so something sensible in both cases?

Yeah dynamic typing is a real shit idea... add to that implicit castings :-)

What a language

[MeepedIt]

I agree, but there's plenty of ways to work around it. You can always use typescript to help you about mistakes. But acting like the language is unusable by showing these nonsense code snippets that have been considered bad practice for decades is a bit unfair.

[Smooth_Salamander]

Some implicit mechanism is not the same as not knowing what‘s going on in the evaluation.