Proofs are, in fact, much less bearable than tests.

This leads to manual fudges in proofs and usage of `auto` and `crush` tactics that behave as gradient descent in the proof space. If they find a proof, you can’t know is it sane or they made a shortcut using existing variable of some type.

So, for instance, any proof assistants if asked to prove existence of function returning `Maybe` using automatic tactics will surely answer “yes”, because, you know, there is `Nothing`.

And if you are doing proofs manually, you are writing another program, in fact, so it gave you nothing, but a wall of code to hide fudges behind.

I personally prefer property-based test frameworks like `quickcheck`/`smallcheck`. They cannot prove, but at least they give me counterexamples to work with.

]]>I cannot agree with you here. I’ve seen haskell codebase of 65k lines long, and my task was to encapsulate things for it to be taken apart.

Encapsulation is a way for _leather bags_ we are to minimise amount of objects to hold in memory at once; it’s not an OOP invention.

]]>