> Discovering that the car you ordered is a pizza is not something you just... abort and undo/ redo. It's: wtf did you do? My age is "pizza", your name is the function "not", your account balance is a database connection. It's ridiculous to say the least and using a tool that makes that > 0% probability is just awful.

Agree, which is why I think the author proposal of just ignoring them (he's using this as an argument to say that runtime type checks are useless, cause they crash the program) makes no sense.

In practice, if the car I ordered is a pizza, I want to know! In production, thanks to unit/integration tests with reasonable coverage, dynamically typed languages will typically exhibit typing errors in very unusual circumstances, typically in branches or combinations that are rarely exercised (otherwise the testing infrastructure would have uncovered the bug), typically much later after the code was written. So, yeah, I don't think any proposal of "just get rid of the checks" deserves to be taken seriously.

But neither do I think your implicit proposal of "just crash everything cause somewhere some very unusual request received the wrong type" makes sense, at least not for large scale reliable software. Just cancel the very unusual request (and recover safely, and make sure to log the very unexpected situation), but don't turn a single request failure into a huge outage.

I think languages should aim to detect these inconsistencies statically, at compile time, as much as feasible. Failing that, they should aim to detect them at "test time". Failing that, at runtime.