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.

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?

So? Language is irrelevant here. What matter is the contract, the agreement that operates through time and space between caller and callee on behavior and expectations. Contracts exist outside of the type system. All a type system can do is enforce a subset of the contractual requirements.

For example, log(0) is undefined. If you write a function to compute log(x), you can (and should) document the function as having unspecified behavior when x is zero.

That's the contract.

The contract holds whether the function is spelled like this

  // x must be positive number
  function log(x) { return ... }

  // x must be positive
  function log(x: number): number { ... }

Likewise, you could define a version of log that accepted, e.g. spelled numbers, like log("three"). You can express this weird contract with static or dynamic typing.

The nasty thing is that if early in the log library's history, before the author wrote down the contract or even had TypeScript, someone had written log("three") and gotten a type error, the log library's author might have "fixed" the "bug" by checking for spelled numbers as inputs. That would have been an expansion of the function's contract.

The log library author probably wasn't thinking about the long-term downsides of this expansion. He could have, even when our log() was a pure-JavaScript, just said "The contract is the input is a positive number. Your code is buggy."

But our hypothetical log library author didn't have the experience or good judgement to say no, so we ended up with the kind of "corner case bloat" the article's author describes.

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!

(Pip used to be right up there next to setuptools. It's still pretty popular — https://pypistats.org/packages/pip — but uv has clearly changed the equation.)

For example, this is a completely empty rust crate, which I started years ago and never released, and it's still downloaded multiple times per day... https://crates.io/crates/ruble

That is a really weird definition of clamp. I would expect to consistently get either min, max, or an error.

I bet Rust doesn't use your weird idea... Yep. Fully sane implementation:

https://docs.rs/num/latest/num/fn.clamp.html

If you're going to smug, at least do it when you're on the right side of the technology. The problem the article describes has nothing to do with the degree of static typing a language might have. You can make narrow, tight, clean interfaces in dynamic languages; you can make sprawling and unfocused ones in statically-typed languages.

The problem is one of mindset --- the way I'd do it, an insufficient appreciation of the beauty of parsimony. Nothing to do with any specific type system or language.

Untyped languages force developers into a tradeoff between readability and safety that exists only to a much lesser degree in typed languages. Different authors in the ecosystem will make that tradeoff in a different way.

‘’’ export function clamp(value: number | string, min: number | string, max: number | string): number { if (typeof value === 'string' && Number.isNaN(Number(value))) { throw new Error('value must be a number or a number-like string'); } if (typeof min === 'string' && Number.isNaN(Number(min))) { throw new Error('min must be a number or a number-like string'); } if (typeof max === 'string' && Number.isNaN(Number(max))) { throw new Error('max must be a number or a number-like string'); } if (Number(min) > Number(max)) { throw new Error('min must be less than or equal to max'); } return Math.min(Math.max(value, min), max); } ‘’’

Some libraries take a `TryFrom<RealType>` as input, instead of RealType. Their return value is now polluted with the Error type of the potential failure.

This is a pain to work with when you’re passing the exact type, since you basically need to handle an unreachable error case.

Functions should take the raw types which they need, and leave conversation to the call site.

I remember writing Python and Perl where functions largely just aimed you passed them the correct types (with isolated exceptions where it may have made sense) years before JavaScript was anything but a browser language for little functionality snippets. It's a dynamic language antipattern for every function to be constantly defensively checking all of it's input for type correctness, because despite being written for nominal "correctness", it's fragile, inconsistent between definitions, often wrong anyhow, slow, and complicates every function it touches, to the point it essentially eliminates the advantages of dynamic language in the first place.

Dynamic languages have to move some responsibility for being called with correct arguments to the caller, because checking the correctness of the arguments correctly is difficult and at times simply impossible. If the function is called with the wrong arguments and blows up, you need to be blaming the caller, not the called function.

I observe that in general this seems to be something that requires a certain degree of programming maturity to internalize: Just because the compiler or stack trace says the problem is on line 123 of program file X, does not mean the problem is actually there or that the correct fix will go there.

Not language specific. A C example that comes to mind is checking every non-nullable pointer parameter in every function for NULL and reporting an error instead of just letting the program crash. (Please, don't do that: just let contract violations produce crashes.)

The article's author describes a problem of experience and spirit, not a language wart.

So are you saying the author updated the implementation and added deprecation warning?))

And author is not "stupid". More like "strategic". popular npm package = money. this is why everybody falls over to write leftpads and stuff.

At some point someone went "let's decouple as much as we can! A library should be just a single function!" and we've spent a lot of time since then showing why that's quite a bad idea

The lack of types perhaps inspires some of these functions masquerading as libraries, but they're often trivial checks that you could (and probably should) do inline in your less pointless functions, if needed.

A lot of times you have something in Java which could be

   ReturnValue someMethod(Parameter p) {
      …
      var x = anotherMethodThatMightThrowAnException(q);
      …
   }

I’ll argue that (1) error handling is a function of the application as a whole or of a “unit of work” (e.g. database transaction) so unless you’re at the top level method of a unit of work you should “let it throw”, (2) try-finally is preferable to try-catch when it comes to cleaning up and tearing down, and (3) it is fair to wrap and rethrow exceptions if you want the unit of work manager to have more context to know what to do, or provide a better error message.

In theory, you could spend time writing and maintaining error preempting and handling code and get better error messages. However that code isn’t always correct. One funny thing about AI agent programming for me is that if I ask Junie to code me some tests it works harder at testing unhappy paths than I would.