this post was submitted on 05 May 2025
483 points (98.8% liked)

Programmer Humor

23052 readers
2136 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

founded 2 years ago
MODERATORS
 
top 50 comments
sorted by: hot top controversial new old
[–] m_f@discuss.online 239 points 2 days ago (2 children)

If anyone's wondering why:

>> 0.000005
0.000005
>> 0.0000005
5e-7
[–] towerful@programming.dev 84 points 1 day ago (1 children)

Yup. parseInt is for strings.
Math.floor, Math.ceil, Math.round or Math.trunc are for numeric type "conversions" (cause its still a float)

[–] mmddmm@lemm.ee 46 points 1 day ago* (last edited 1 day ago) (4 children)

Nah, it's stupid either way.

"5e-7" is not an int to be parsed. Neither is "0.5".

[–] ThirdConsul@lemmy.ml 7 points 1 day ago* (last edited 1 day ago) (2 children)

Ah, folly of untyped systems. Tbh this behaviour makes sense given the rules implemented within the language. Anything passed to parseInt is casted to string and then parsed.

Is it shitty behaviour - yes. Does it make sense in given the language implementation - yes.

[–] frezik@midwest.social 3 points 23 hours ago* (last edited 23 hours ago)

When handling things that are serialized over the wire, you have to do it this way. Yes, you can use typed serialization formats, but in a string-based serializer, there's nothing stopping the other system from sending "0.0000005" on a field that should be an int. If you don't validate that it's an int, you would just pass that value to your equivalent of parseInt().

If you do validate that it's an int, then it still didn't matter if the language has static typing or not. You're doing that at runtime or you're not.

In Rust, doing "0.00005".to_string().parse::<i32>().unwrap() causes a panic on the unwrap() from an invalid digit. However, that's runtime. It's not something the type system can handle statically. The real benefit here, I think, is that it at least forced you to consider that the invalid input could have unexpected results. This is a pretty good reason to be careful about putting unwrap() on everything. The compiler isn't going to save you here.

[–] LarsIsCool@lemmy.world 3 points 1 day ago (1 children)

With this reasoning, would you say everything that a computer does makes sense, because it always follows the implementation? Or am I missing something?

[–] ThirdConsul@lemmy.ml 1 points 17 hours ago

Bar space-level problem where radiation can randomly shift your bits, I think yes.

[–] LeninOnAPrayer@lemm.ee 62 points 1 day ago* (last edited 1 day ago) (5 children)

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.

[–] JakenVeina@lemm.ee 11 points 1 day ago

The REAL problem is that the industry collectively uses JS almost exclusively for shit it was never meant to do. Like you say, it's intended for it to not throw errors and kill your whole web page, because it was only ever intended to be used for minor scripts inside mostly-static HTML and CSS web pages. Then we all turned it into the most-popular language in the world for building GUI applications.

[–] leftytighty@slrpnk.net 42 points 1 day ago

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.

[–] mmddmm@lemm.ee 10 points 1 day ago

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.

[–] Blackmist@feddit.uk 5 points 1 day ago

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.

load more comments (1 replies)
[–] ICastFist@programming.dev 5 points 1 day ago

Javascript: "They're the same thing"

load more comments (1 replies)
[–] Jankatarch@lemmy.world 2 points 1 day ago

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?

[–] Blackmist@feddit.uk 33 points 1 day ago

Good old JS, because exceptions are a sin.

[–] danda@lemmy.zip 100 points 2 days ago (2 children)

It's because parseInt is expecting a string, so the decimal gets converted to a string, and 0.0000005.toString() returns 5e-7.

[–] KindaABigDyl@programming.dev 43 points 2 days ago (1 children)

More like javascript L, even python would throw a TypeError for this example.

[–] spizzat2@lemm.ee 31 points 1 day ago* (last edited 1 day ago) (1 children)

And to further expand on that, if you do pass in a ~~sting~~ string, it handles it correctly.

> parseInt('0.0000005')

0
[–] SpaceNoodle@lemmy.world 18 points 1 day ago* (last edited 1 day ago) (2 children)

What if I pass in a Stewart Copeland?

[–] spizzat2@lemm.ee 9 points 1 day ago

😆 I'll be watching you...

[–] xtools@programming.dev 3 points 1 day ago

or a Honda civic

[–] miellaby@jlai.lu 21 points 1 day ago

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.

[–] heavy@sh.itjust.works 47 points 1 day ago (5 children)

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

[–] tauonite@lemmy.world 16 points 1 day ago* (last edited 1 day ago) (1 children)

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

[–] Lemminary@lemmy.world 6 points 1 day ago (1 children)

Is it? I've seen longer articles for C# and not as many complaints about it.

[–] barsoap@lemm.ee 5 points 1 day ago

Probably not an article about integer parsing, though. If the docs are that long, then because Microsoft does have a tendency to be overly verbose for things they think you need, just to have no docs for the stuff you actually need.

For reference here's the relevant rust docs.

[–] barsoap@lemm.ee 14 points 1 day ago* (last edited 1 day ago)

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.

[–] FiskFisk33@startrek.website 4 points 1 day ago

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().

[–] Zacryon@feddit.org 9 points 1 day ago (2 children)

I'd advise to always look into the corresponding documentation before using something from any library.

[–] bisserkr@lemmy.world 13 points 1 day ago

I'll go with 5 hours of debugging, thank you very much!

[–] pinball_wizard@lemmy.zip 4 points 1 day ago

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.)

[–] jsomae@lemmy.ml 4 points 1 day ago* (last edited 1 day ago)

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

[–] RandomVideos@programming.dev 2 points 1 day ago* (last edited 1 day ago)

If(x-parseInt(x)<0){ y=0;} Else{ y=parseInt(x)!}

[–] FMT99@lemmy.world 51 points 2 days ago (25 children)

Another classic javascript wat

load more comments (25 replies)
[–] mariusafa@lemmy.sdf.org 21 points 1 day ago (2 children)

What language is that so I can avoid it.

[–] crusa187@lemmy.ml 42 points 1 day ago

lol it’s js of course

[–] Blackmist@feddit.uk 8 points 1 day ago

We all know what it is.

[–] glowing_hans@sopuli.xyz 11 points 1 day ago

looks functional to me. Its a pure function, right?

[–] enemenemu@lemm.ee 11 points 2 days ago

Great feature

load more comments
view more: next ›