It leads to less code, and more generalizable code. Maybe the caller does know what they're doing, who am I to say they can't.
What happens is you get an error. So you immediately know something is wrong.
Javascript goes the extra mile to avoid throwing errors.
So you've 3>"2" succeeding in Javascript but it's an exception in python. This behavior leads to hard to catch bugs in the former.
Standard operators and methods have runtime type checks in python and that's what examples in the article are replicating.
Don’t most languages have the same problem? Even C or Rust have escape hatches that let you override compile-time type checking and pass whatever gibberish you want to a function. How is Typescript any worse?
I’ll pull off the cleanest, nicest generic constraints on some component that infers everything perfectly and doesn’t allow invalid inputs, just for a coworker to throw @ts-nocheck on the entire file. It hurts
export function clamp(value: number, min: number, max: number): number { return }
That is just adding an extra jump and entry on the callstack where you could just have done:
Math.min(Math.max(value, min), max);
Where you need it.
(The example used was probably just for illustration though)
i disagree with this particular example - it's actually a good use case for being a utility maths function in a library.
I mean, the very `min()` and `max()` function you used in the illustration could also have been used as an example, if you use the same logic!
In terms of DRY and cleanliness, yes "clamp" sounds awesome. But in terms of practicality and quick understanding? Math.min and Math.max there is such a frequent pattern that brain immediately understands what is being tried to do there, as opposed to exact meaning of "clamp" to me.
It may be just me though, clamp is not a word I frequently hear in English, and I see it in code sometimes, but not frequently enough to consciously register what it does as fast in my brain. Despite seeing code for probably 8h+ a day for the past 10 years.
If it was in std lib of JS, maybe then it would be better.
Like there is some sort of balance line on how frequently something is used and whether it's REALLY worth to abstract it. If it's in stdlib, use it, if it's not use it if truly it's pretty much always used.
I'm also coming from being a Go programmer where the native library is very barebones so a lot of custom utility methods like this are inevitable.
C++: https://en.cppreference.com/w/cpp/algorithm/clamp.html
.NET/C#: https://learn.microsoft.com/en-us/dotnet/api/system.math.cla...
Java: https://docs.oracle.com/en/java/javase/24/docs/api/java.base...
Ruby: https://ruby-doc.org/core-2.4.0/Comparable.html#method-i-cla...
Rust: https://doc.rust-lang.org/stable/std/primitive.f64.html#meth...
Are there 1000 people running 100 CI pipelines/day where downloads aren’t cached?
It'd be a lot more productive to ask the authors of the (normally bigger, user-facing) libraries that you use nowadays to avoid using these libraries with deep and outdated dependencies. e.g. I stopped using Storybook because of this, but I'm happy to see that they've been working on cleaning up their dependency tree and nowadays it's much better:
Oh, look, somebody just re-discovered static typing.
Functions near the core can assume more and code less defensively than those near the edge.
Libraries shouldnt be edge case first? What? /What kind/ of libraries? You really can’t imagine a library where it makes sense to code very defensively?
Also the post doesn’t even use “edge case” correctly. Definitionally you can’t have an edge case before you’ve defined the acceptable input. In their clamp function the edge case would be something like a large number on the border of graduating from long to BigInt or something. Edge case does not mean invalid input. Edge case is a rare/extreme input that is valid.
It's not about performance, it's about separating concerns: the caller handles the not-a-number case, so the callee doesn't have to.
Then you add optional runtime checking of the contract, preferably in a different build mode (or a different version, e.g. "my-lib1.2-debug"), to get sensible diagnostics quickly in tests and canary deployments. The checks are redundant by definition. Defensive programming.
01HNNWZ0MV43FF•2h ago
ants_everywhere•2h ago
mewpmewp2•1h ago