3 ms·

> 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 f

by afc 5y ago

> 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.

hurril 5y ago
I disagree completely. Having runtime checks or not if the code that's written is basically randomly stringed together expressions, are all unsound code. This is runtime type-checks: if x == null: die "Nullpointer exception"; it is simply not better than: x.DoTheThing(); They are equivalent. The solution to that is not a runtime check, it's actually using a typing system in the first place. Runtime type-checks is no different from: let x = 42; if x != 42: die "It's supposed to be 42"; compute_the_thing x; if x != 42: die "It's supposed to be 42"; save x; if x != 42: die "It's supposed to be 42"; Only completely unsound code would rely on something like that. I know that I'm not checking types in my pretend-o-code. "In practice, if the car I ordered is a pizza, I want to know!" I would say that this is misusing my analogy by flirting with simple value bugs. Ordering a thing and getting the wrong kind of product, that's perfectly understandable in the world of bugs and what not. Calling the place_order function, expecting to get back an order object but instead getting the function "not" or a database connection, that's more akin to what we're talking about here. It's the wrong data type and having a runtime check to catch that is a sign of dealing with unsound code. Just crash everything is what _you_ are suggesting because that failing runtime type-check _is_ a de facto runtime crash of whatever was running at that point. Code that runs the risk of encountering such a problem should not compile because it's not even wrong.

by afc 5y ago

hurril 5y ago

I disagree completely. Having runtime checks or not if the code that's written is basically randomly stringed together expressions, are all unsound code. This is runtime type-checks: if x == null: die "Nullpointer exception"; it is simply not better than: x.DoTheThing(); They are equivalent. The solution to that is not a runtime check, it's actually using a typing system in the first place. Runtime type-checks is no different from: let x = 42; if x != 42: die "It's supposed to be 42"; compute_the_thing x; if x != 42: die "It's supposed to be 42"; save x; if x != 42: die "It's supposed to be 42"; Only completely unsound code would rely on something like that. I know that I'm not checking types in my pretend-o-code. "In practice, if the car I ordered is a pizza, I want to know!" I would say that this is misusing my analogy by flirting with simple value bugs. Ordering a thing and getting the wrong kind of product, that's perfectly understandable in the world of bugs and what not. Calling the place_order function, expecting to get back an order object but instead getting the function "not" or a database connection, that's more akin to what we're talking about here. It's the wrong data type and having a runtime check to catch that is a sign of dealing with unsound code. Just crash everything is what _you_ are suggesting because that failing runtime type-check _is_ a de facto runtime crash of whatever was running at that point. Code that runs the risk of encountering such a problem should not compile because it's not even wrong.