6 ms·
This concept is really interesting when you think about statically typed, pure functional languages. I like working in them because I'm too pretty and stupid to
by 1-more 1y ago
This concept is really interesting when you think about statically typed, pure functional languages. I like working in them because I'm too pretty and stupid to think about side effects in every function. My hair is too shiny and my muscles are too large to have to deal with "what if this input is null?" everywhere. Can't do it. Need to wrap that bad boy up in a Maybe or some such and have the computer tell me what I'm forgetting to handle with a red squiggly.
- 9rx 1y agoFormal proof languages are pretty neat, but boy are they tedious to use in practice. It is unsurprising that effectively no code is written in them. How do you overcome that? Where the type system isn't that expressive, you still have to fall back to testing to fill in the places where the type system isn't sufficient, and your tests are also going to 'deal with "what if this input is null?" everywhere' cases and whatnot by virtue of execution constraints anyway.
- 1-more 1y agoI'm just talking null-less FP languages such as Haskell and Elm, not a full proof system such Lean and Agda or a formal specification language such as TLA+. I'm not sure I agree with your prior that "your tests are also going to 'deal with "what if this input is null?" everywhere' cases and whatnot." Invalid input is at the very edge of the program where it goes through a parser. If I parse a string value into a type with no room for null, that eliminates a whole class of errors throughout the program. I do need to test that my parser does what I assume it will, sure. But once I have a type that cannot represent illegal data, I can focus my testing away from playing defense on every function.
- 9rx 1y agoAssume that there was room for null. What is your concrete example of where null becomes a problem in production, but goes unnoticed by your tests?
- 1-more 1y agoIn a world where I am writing a language with null and have half-implemented a grown up type system by checking for null everywhere and writing tests that try to call functions with null (EDIT: and I remembered to do all of that), I guess we could say that I'm at the same place I am right now. But right now I don't have to write defensive tests that include null. You're asking about a circumstance that's just very very different from the one I'm in.
- 9rx 1y ago> But right now I don't have to write defensive tests that include null. You seem to misunderstand. The question was centred around the fact that unexpected null cases end up being tested by virtue of you covering normal test cases due to the constraints on execution. Explicitly testing for null is something else. Something else I suggest unnecessary — at least where null is not actually part of the contract, which for the purposes of our discussion is the case. Again, we're specifically talking about the testing that is necessary to the extent of covering what is missing in the type system when you don't have a formal proof language in hand. > You're asking about a circumstance that's just very very different from the one I'm in. But one you've clearly had trouble with in the past given your claims that you weren't able to deal with it. Otherwise, how would you know? Perhaps I can phrase my request in another way: If null isn't expected in your codebase, and your testing over where the type system is lacking has covered your bases to know that the behaviour is as documented, where are the errant nulls going to magically appear from?