[agentultra]

I think there needs to be a version of this for pure FP languages like Haskell or even OCaml or F#; almost none of these maxims and aphorisms seem to apply.

Abstraction? It has a completely different meaning in this context. Our business is abstraction: creating precise definitions and semantic meaning where none existed before. It is much easier to create abstractions and sufficiently demonstrate their laws hold. So much so that we often design our programs and libraries with abstractions first.

This forces our programs to deal with the side-effects of interacting with the world outside of our programs' memory-space at the very edges of our program. We can prove a great deal of our code is correct by construction which lets us focus our testing efforts on a much smaller portion of our programs.

However even in non-FP languages I think a lot of these problems do go away if you use the above definition of abstraction and spend a bit more time thinking about the problem up front before writing code. Not too much, mind you, because the enemy of a good plan is a perfect one; however enough that you know what the essential properties and laws are at least tends to help and reduce the amount of code you need to consider and write.

[avgcorrection]

FP has a better definition of abstraction where it is closer to the sense of “simplify”.

In procedural programming it might just mean indirection. Or silly metaphors.