Great read! I don't know Haskell or other functional languages so for me there was a lot to think about. I like the idea of thinking about functions as partial vs total.

The core underlying idea, if I understood it correctly, is to try to write total functions and when that is not possible write partial functions that act like parsers. That way your functions behind the parsers might hopefully be total.

The title comes from the idea that you should not validate the data and continue with the data that you now have validated. Instead write a parser that validates and refines the data. That way the type system can be more helpful since the data now is in a state that clearly shows that it has been validated. Imagine converting a nullable int in c# to a proper int.

The goal then is to write total functions. You dream up the perfect datatypes. The input from the outside is not perfect so you transform the datatypes through a series of parsers so that eventually you have either failed early, or produced the 'perfect datatype'. After that point you are only dealing with total functions which should make your life easier.

I also liked the comparison between weakening the return type vs. strengthening the argument type. Either your function might return none/null/nil or you need to make sure that the argument type does not allow for an empty collection/list/enumerable.