parseInt(5)

If anyone's wondering why:

>> 0.000005 0.000005

>> 0.0000005 5e-7
- Yup. parseInt is for strings.
  Math.floor, Math.ceil, Math.round or Math.trunc are for numeric type "conversions" (cause its still a float)
  
  Nah, it's stupid either way.
  "5e-7" is not an int to be parsed. Neither is "0.5".
- I actually don't hate this. Like I love C because it lets me mess around with how stuff internally work. This just sounds like a fun concept. If it was 5000000000000 would it also parse as 5?

I also like this one:

>> typeof(NaN) "number"
Sure, technically it makes sense, but read it out loud

It's because parseInt is expecting a string, so the decimal gets converted to a string, and 0.0000005.toString() returns 5e-7.
- Common Dynamic Typing L
  
  More like javascript L, even python would throw a TypeError for this example.
- And to further expand on that, if you do pass in a ~~sting~~ string, it handles it correctly.
  
  > parseInt('0.0000005') 0
  
  What if I pass in a Stewart Copeland?

I know this is for fun, but as general advice to the homies, if a language or system is doing something you didn't expect, make sure to look at the documentation
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/parseInt
This will save a lot of time and headaches
- https://en.wikipedia.org/wiki/Principle_of_least_astonishment
  ...and of course JS made it into the examples, how could it not:
  A programming language's standard library usually provides a function similar to the pseudocode ParseInteger(string, radix), which creates a machine-readable integer from a string of human-readable digits. The radix conventionally defaults to 10, meaning the string is interpreted as decimal (base 10). This function usually supports other bases, like binary (base 2) and octal (base 8), but only when they are specified explicitly. In a departure from this convention, JavaScript originally defaulted to base 8 for strings beginning with "0", causing developer confusion and software bugs. This was discouraged in ECMAScript 3 and dropped in ECMAScript 5.
- Holy fuck that is long. When the documentation for the integer parsing function is 10 pages long, there's something seriously wrong with the language
  
  Is it? I've seen longer articles for C# and not as many complaints about it.
- I'd advise to always look into the corresponding documentation before using something from any library.
  
  I'll go with 5 hours of debugging, thank you very much!
  
  But I'm too busy being confused by the behaviors of libraries I previously didn't read the documentation for, to read the documentation for every new library I adopt.
  (This is sarcasm...mostly.)
- oh god the reason is even stupider then I expected
  Because large numbers use the e character in their string representation (e.g., 6.022e23 for 6.022 × 1023), using parseInt to truncate numbers will produce unexpected results when used on very large or very small numbers. parseInt should not be used as a substitute for Math.trunc().
- Okay but this documentation is obviously wrong from the first sentence
  The parseInt() function parses a string argument and returns an integer of the specified radix
  Integers don't have radices. It should read:
  The parseInt() function parses a string argument representing an integer of the specified radix and returns that integer.
  ~~Either way, I still don't understand the behaviour in the image.~~ nvm, thanks m_f@discuss.online

Good old JS, because exceptions are a sin.

Another classic javascript wat
- Classic people who don't know how to code wat. Passing a number in place of a string argument because they don't know what they're doing.
  
  Javascript could throw an error to alert you that the input is supposed to be a string, like most languages would do.
  
  It's not a string argument though, it's JS. You can argue it's expected to be a string but like the rest of JS all you can know from the signature alone is that it takes an object. Hopefully your little ducky quacks the right way!
  
  Could be a variable from somewhere else in the code. It should throw type error of some sort if it's not going to handle a float correctly
  
  What do you mean, you don't use string parsing method to round to integers? /s

I've seen code in my workplace using parseInt to round JS Number. Made me cringe coming from system programing but I didn't see the danger.
It's sad the only way to prevent such a bad code in production is to use transpilers.