I like the article and think it makes some good points, but I can't help but think the author is cheating a bit. If you really want to show the extent to which

I like the article and think it makes some good points, but I can't help but think the author is cheating a bit. If you really want to show the extent to which a language can be inherently reasoned about, it seems like a slight-of-hand to provide hints in the names. Take a look at this snippet from example 6: // create a repository var repo = new CustomerRepository(); // find a customer by id var customer = repo.GetById(42); The fault is "I can't tell by looking at this code whether a null is returned or not." The improvement is this (in a language without nulls or exceptions): // create a repository var repo = new CustomerRepository(); // find a customer by id and // return a CustomerOrError result var customerOrError = repo.GetById(42); Aside from the comments and a change to the variable name, isn't this code identical? The fact that subsequent code must process the result specially if the input (42) is garbage is true of any language, whether or not null is allowed. I still can't tell "by looking at it" what is happening. In fact, I would reason differently about this code if the comments were removed and the names changed: var a = new B(); var c = d.E(42); In this context, it seems the real error is that an invalid parameter value is passed, so I'd see if I could fix that first, possibly eliminating the need for any error handling code. That approach might be common for a functional mindset, but not exclusively so.