302
parseInt(5)
(lemmy.ml)
Good old JS, because exceptions are a sin.
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.
looks functional to me. Its a pure function, right?
What language is that so I can avoid it.
We all know what it is.
lol it’s js of course
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.
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
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!
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".
People give JS a lot of shit. And I do too. But it's meant to continue running and not fail like C code would. It's meant to basically go "yeah, sure I'll fuck with that" and keep trucking.
So you can always make it do stupid shit when you use it a stupid way.
Is this bad? Maybe. Was it the intention of the language? Absolutely.
Typescript fixes a lot of these headaches. But I feel like JS is doing exactly what it was meant to do. Keep trucking even when the programmer asks it to do stupid shit.
If you're using JS and don't understand this then it's your fault and not the languages fault.
Do we all want to live in a world of typedefs as strict as C and have our webpages crash with the slightest unexpected char input? Probably not.
We don't notice all the time JS goes "yeah I can fuck with that" and it works perfectly. We only notice the times it does that and it results in something silly.
TLDR: JS does what it was made to do. And because of that it looks absolutely ridiculous sometimes.
It’s meant to basically go “yeah, sure I’ll fuck with that” and keep trucking.
Yet, it lives in an insulated environment, with plenty of infrastructure to make sure errors do not propagate, with a standard error handling functionality on the spotlight with specialized syntax, and with plenty of situations where it just drops the ball and throws an error.
Nope, not falling for the gaslight. It's a stupid feature that's there because the language was created during a week and the author was trying to juggle the requirement of a rigid and typed semantics that looked like Java with his desire to make a flexible single-typed language that looks like Lisp.
And nobody fixed it, decades later, because everybody keeps repeating your line that the interpreter must always keep on.
My main issue with JS is you can use it wrong, and it pretends to work, and often looks like it works.
But then shits its pants explosively the second you fall outside that.
People forget that crashes are a debugging tool indicating an error. Silent errors can be much more dangerous. C and C++ in particular need to be careful not to overwrite random memory for example.
Yes the consequences for JS failures are less severe and so JS can get away with it, but a crash is a way to know your program isn't doing what you thought it was, properly.
It just so happens that JS is used in contexts where nobody really cares, and errors aren't a big deal, cheap and fast wins.
That's not why JS is a big pile of crap. It's because the language was not thought through at the beginning (I don't blame the inventors for that) and because of the web it spread like wildfire and only backwards compatible changes could be made. Even if will all your points in mind the language could be way nicer. My guess is that once wasm/wasi is integrated enough to run websites without JS (dom access, etc.) JS will be like Fortran, Cobol and Telefax - not going away any time soon, but practically obsolete.
Javascript: "They're the same thing"
It's because parseInt is expecting a string, so the decimal gets converted to a string, and 0.0000005.toString() returns 5e-7.
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 Sterwart Copeland?
or a Honda civic
😆 I'll be watching you...
Common Dynamic Typing L
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.
But you're calling a function specifically made for passing a string to an int... 😆 There's gotta be some common sense somewhere here, guys.
Still, it's a very good point. JS should do this.
I would suspect one reason it doesn't do this is to be backwards compatible.
Theoretically, Javascript is an untyped language, so there aren't supposed to really be static types. Giving type errors in this situation would be against design.
Maybe the design is bad, then.
Lol you'll get no argument from me. It's not my favorite language.
JavaScript has types and it does have type errors, for instance
> null.foo
Uncaught TypeError: null has no properties
Please stop spouting nonsense on issues you know nothing about.
Dynamic types aren't static types my man. I think you got some learning to do.
Theoretically, Javascript is an untyped language…
Function only handles string arguments correctly. Wat.
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!
It's not a string argument though, it's JS
Huh? The code in the image is passing a number argument where there should be a string argument.
And this function is specifically made to parse a string into an int. Apply common sense.
JavaScript doesn't have typed parameters or variables. The function expects a string and does things in the function body which converts the object into a string. JS shares this behavior with all dynamically typed languages and it's extremely useful in some contexts and extremely frustrating in others. It's down to what it's being used for. Dynamic languages make excellent scripting languages, see Python really just being a souped up shell lang
The function expects a string and does things in the function body which converts the object into a string.
... These are different words that describe exactly what I'm saying. I'm saying: in the place where there should be a string argument, because the function expects one, there is not a string argument, but a number argument. (Not an object like you keep saying.)
I know all that stuff about dynamically typed languages. I'm just saying that the function is being used indirectly here.
You cannot have a string argument, arguments and variables in JS don't have a type. All you have in JS is objects. Actual functions, like full on function foo(){} are still objects, like you can actually store data on the things.
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
Agreed, functions in general should do this, and some do. But it should probably be automatic. And the variable argument is a good one, a very good argument for TypeScript. ❤️
What do you mean, you don't use string parsing method to round to integers? /s
Love you 😆
Great feature
this post was submitted on 05 May 2025
302 points (99.0% liked)
Programmer Humor
23025 readers
1321 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS