Comment by galaxyLogic
11 hours ago
(In Haskell) > just adding a simple print somewhere is not going to work without refactor
Interesting. How do people cope with this in practice? Does it mean you can't really use log() -statements for debugging?
11 hours ago
(In Haskell) > just adding a simple print somewhere is not going to work without refactor
Interesting. How do people cope with this in practice? Does it mean you can't really use log() -statements for debugging?
You just add `trace`. It's not hard.
https://wiki.haskell.org/Debugging
There is always `trace`.
https://wiki.haskell.org/Debugging#Printf_and_friends
Whoa you were faster than me!
You could wrap it in an unsafeIO function to make it return `()` again.
However, I’ve had very little use of printing for debugging. In Haskell you write small (ish) and pure functions that you can test extensively with property based testing. The types already help a lot as well.
So basically the only place where you deal with unexpected input is at the communication boundaries of the app where you are in some form of IO already and printing just available.
That's fine for a library or locally run executable, but I've worked on distributed systems in Haskell and you really need logging in place to track what is going on.
Of course, you will have IO somewhere in a executable where you can handle logging so just separate pure and IO and make sure you have good tests for the pure functions. Also, linting to catch partial functions and dangerous lazy ones (or use an alternative prelude).
Sure you want logging and tracing (in the RPC sense not Debug.Trace.trace).
Most of this can still be done from IO places where the pure functions collect enough error information bubbling up (e.g. content and line/col of parser errors etc.) to not need ad hoc print statements for debugging.
2 replies →