[mchaver]

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).

[spockz]

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.

[jappgar]

In practice this just doesn't happen because you've composed a bunch of pure functions with various branches within them.

You lose the ability to log "why" some effect is happening.

[spockz]

Eh sure. But you can always collect/carry decisions in something like an Either. When using arrows or your own monadic bindings it is even possible to abstract this away from view.

[mchaver]

Yes, definitely wouldn't use print because in an async environment that will get garbled. A proper logging library is the way to go.