Are JS developers literally subhuman?

But it werks, I can't imagine a decent replacement.

>>61527899
>js is doing this right and its specified this way

File: Screen Shot 2017-07-23 at 22.41.24.png (106KB, 688x552px) Image search: [Google]

106KB, 688x552px

>>61527899

File: last.png (5KB, 484x268px) Image search: [Google]

5KB, 484x268px

Nice language, C """devs""".

File: last.png (4KB, 484x268px) Image search: [Google]

4KB, 484x268px

Nice language, Ruby """devs""".

>>61528563
>forcing it to be a floating point value with .0 AND the f suffix

>>61528036
>completely irrelevant problem that exists in the idea of floating-point

2/10 for effort

File: last.png (4KB, 484x268px) Image search: [Google]

4KB, 484x268px

Nice language, Python """devs""".

>>61528597
>It's Ruby's fault for floating-point arithmetic problems

>>61528632
That's the point, I'm making fun of OP.

File: last.png (6KB, 484x268px) Image search: [Google]

6KB, 484x268px

>>61528601
Here, have another (You), that's literally the same user error.

>>61528601
>two issues that both revolve around storing values in 32 bits are totally irrelevant
ok m8

  0 == "" 
  0 == "0"
  0 == " \t\r\n " 
  "0" == false 
  null == undefined 
  
  ""    != "0" 
  false != "false"
  false != undefined
  false != null

>>61528720
Doesn't C give you compiler warnings with numbers that are too big?

>>61528764
Depends on the compiler, you get the exact same warning with any kind of JS linter.

But you're pretty much retarded in any case for using overflowing constants, the actual issues raise when shit overflows at runtime, and the user has to take care to avoid it.

He could have at least made fun of the implicit type cohercion with +, - and String, Number.

>>61528763
>implicitly type coherced equality results in different things being equal

Oh no.

>>61528563

#include <stdio.h>

int main(void)
{
    unsigned long a = 10000000000000000,
                  b = 10000000000000001;
    return printf("%i\n", a==b) == 2;
}

prints 0.

>>61528902
No shit sherlock, they just have different overflowing semantics.

>>61528902
>unsigned long
doesn't overflow

>>61528920
meant for you
>>61528937

typeof NaN
-> number

classic.

File: last.png (3KB, 484x268px) Image search: [Google]

3KB, 484x268px

>>61528960
They overflow to different values, the underlying issue is the same, i.e. not an issue.

>>61528902

You should use unsigned long long for this. Were this compiled on Windows, you'd have an issue, because long would be 32-bit.

>>61528994
Now that's an actual issue with the language, but not for the results it has, for the fact String has an overloaded + (and only +) while nothing else does and you can't overload your own operators.

>>61529021
Thanks for the tip senpai

>>61529076
ignore him you should use uint64_t or uint_fast64_t or uint_least64_t. Every time you write "unsigned" in your program you have no idea how many bits you're getting out. Even `char` doesn't necessarily have to be 8 bits, you have to check with the macro CHAR_BITS

>>61527899

10000000000000000 == 9999999999999999
true