DocTest VS fused-effects-system

doctest for testing examples in the documentation. Docs are much clearer when they contain usage examples and doctest helps them keep up to date.

Try to restrict your types even on sub functions (inside where), use testing, break down your code to the most atomic parts, using ghci to debug each part once at a time, and because Haskell doesn't let you reuse variables, or mutate state, it's a lot easier to rationalize evaluation order (which makes it a lot easier to debug without step debuggers compared to languages like python).

Some may argue that the tests are a form of documentation, and that's true, but they still don't capture the why. And tests are almost always separated from the actual code, which makes it more complicated to look at the code and the tests at the same time and understand them together. I've used doctest with Haskell which is a solution to this. Doctest is nice at first but in my experience it wasn't reasonable to do non-trivial tests in doctest, and plenty of tests are non-trivial. So then you're left with the decision to use doctest where you can, and another test solution for non-trivial tests, or just do all tests using the other testing solution. We chose simplicity and got rid of doctest.

Until some enterprising PhD student comes along and takes a whack at this problem, I debug my programs by: a) using pure functions whenever possible—I am bad at keeping track of imperative execution in my head, and as such pure functions help me avoid the associated mistakes, and what mistakes I do make are more apparent visually; b) using hedgehog or QuickCheck aggressively, so as to verify that the assumptions I’m making are correct; c) when writing imperative/effectful computation, building in logging from the get-go—I am a fused-effects user, so I use the built-in Trace effect as well as fused-effects-profile to yield information about what’s actually being executed.