this post was submitted on 25 Oct 2026
371 points (95.1% liked)

Programmer Humor

33823 readers
2008 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 3 years ago
MODERATORS
anzo@programming.dev
Feyter@programming.dev
BurningTurtle@programming.dev
pylapp@programming.dev
371
Anon died on the "clang format bad" hill (programming.dev)
submitted 3 days ago by danhab99@programming.dev to c/programmer_humor@programming.dev
542 comments fedilink hide all child comments
 

Mine is that the useState hook is an actual plague on the entire React ecosystem. Regardless of your opinions of React, if you wanna use something then use it right.

you are viewing a single comment's thread
view the rest of the comments
[โ€“] lapping6596@lemmy.world 3 points 1 day ago (1 children)

Okay, I do think this makes you sound crazy.

I'm putting my question first before I rant about this cause I think I got way more into this response than is warranted.

What problem does this design of just creating bespoke functions have that your design solves?

def mean(numbers):
    return efficient calculation
def normalization(numbers):
    return efficient calculation
def geometric_mean(numbers):
    return efficient calculation

Rant starts here:

With your design, every time someone wants an average of a set of numbers, you're reimplementing the actual logic. Then if someone forgets the +1 and writes:

quotient_reduce(sum, lambda x,y: x, numbers)

A bug is introduced that's hard to spot in a review, won't give an error, and is hard to write tests for. Turning the lambda to an enum meant to be passed around would solve a some of the accidental bugs, but keeps the interaction with the function more complicated.

I really just don't understand why you wouldn't just write each efficient implementation as it's own function and call it directly.

[โ€“] stingpie@lemmy.world 1 points 1 day ago

It has to do with how you decompose problems. In the example I gave, I was trying to point out that arithmetic average, geometric average, and normalization are related problems. Consider applying this technique to something more complicated than averages: pathfinding. You could create a dozen different efficient functions, each with different considerations, but the core of the algorithm will always be the same. You can write pathfind_land(src, dest), pathfind_sea(src, dest), pathfind_air(src,dest), pathfind_sea_and_land(src,dest) etc. but it's obviously better to write it as pathfind(src,dest, is_traversable) and select the most efficient implementation inside the function. It also allows you to use a not-optimized implementation automatically if you haven't made an efficient implementation.