That said, the biggest problem I've seen in a lot of projects, bigger than coercion and in languages including, but not limited to JS is not properly handling error cases.
That's a HUGE problem. This is an absolutely fucking nightmare. It's arguably the hardest thing to possibly debug, because you're not informed it's a bug. No amount of error handling will solve that, which you've pointed out as "the biggest problem".
> If someone calls me with invalid input, and it's coerced and you get invalid output
But this isn't the problem. The problem is when it gets called with invalid input and somehow gets coerced into a valid but unexpected output. Expected input -> Expected output means you get instant gratification as to whether or not it works. This dramatically reduces the number of error cases which naturally and effortlessly moves toward solving your complaint.
I don't consider it a foresight issue. I'm a believer in putting the burden on the caller not the callee. If I expect 0 and you have "0", it's your job to call parseInt(), not my job to branch out some if statements for type checking and coercion. For a few reasons:
1) debugging someone else's code is a lot more time consuming than debugging your own
2) actually fixing a bug in someone else's code means a pull request to someone who may not actively maintain that code
3) the docs are simpler to write and easier to read.
It's my only pain point with the JS community. The "give me whatever and I'll see if I can handle it for you" mentality:
"`doStuff` takes 2 or 3 arguments, depending on what you feel like giving it."I'd rather be expressly told what to give you than try to read a wall of if statements in both the docs and your code.