3 ms·

(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

(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?

floxy 6mo ago
There is always `trace`. https://wiki.haskell.org/Debugging#Printf_and_friends https://wiki.haskell.org/Debugging#Printf_and_friends
- buggymcbugfix 6mo ago
  Whoa you were faster than me!
spockz 6mo ago
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.
- mchaver 6mo ago
  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 6mo ago
    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 6mo ago
      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 6mo ago
        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 6mo ago
      Yes, definitely wouldn't use print because in an async environment that will get garbled. A proper logging library is the way to go.
buggymcbugfix 6mo ago
You just add `trace`. It's not hard. https://wiki.haskell.org/Debugging https://wiki.haskell.org/Debugging

floxy 6mo ago

There is always `trace`. https://wiki.haskell.org/Debugging#Printf_and_friends https://wiki.haskell.org/Debugging#Printf_and_friends

buggymcbugfix 6mo ago
Whoa you were faster than me!

spockz 6mo ago

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.

mchaver 6mo ago
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 6mo ago
  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 6mo ago
    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 6mo ago
      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 6mo ago
    Yes, definitely wouldn't use print because in an async environment that will get garbled. A proper logging library is the way to go.

buggymcbugfix 6mo ago

You just add `trace`. It's not hard. https://wiki.haskell.org/Debugging https://wiki.haskell.org/Debugging