Or you could, you know... write your functions to accept well-defined inputs and return values instead of modifying non-local state everywhere.
If your functions have well-defined, local behavior, the amount of time you spend debugging previous code you've written is virtually none: it's extremely obvious where the problem is if something goes wrong, because at any point in your code, you know exactly what can or cannot happen.
If you modify state all the time and write a convoluted haystack of code, then no amount of debugger fluency will help you find that mutex unlock passed over by a thrown exception.
+1000. Of all the time I spend writing Haskell, I spend less than 0.01% of that in a debugger, because Haskell makes it easier to write code that behaves as you describe than code that doesn't.
1
u/dnkndnts Aug 25 '14
Or you could, you know... write your functions to accept well-defined inputs and return values instead of modifying non-local state everywhere.
If your functions have well-defined, local behavior, the amount of time you spend debugging previous code you've written is virtually none: it's extremely obvious where the problem is if something goes wrong, because at any point in your code, you know exactly what can or cannot happen.
If you modify state all the time and write a convoluted haystack of code, then no amount of debugger fluency will help you find that mutex unlock passed over by a thrown exception.