I'm not arguing that 'trace' is subversive, rather, most of the time it's simply not necessary (or useful).

Haskell's not like other languages, where you have to build up massive unreadable piles of code to get anything done. It's easier to write properly, with small functions glued together; and when you've done that, debugging is a matter of either simply reading the code, or running it in GHCI (and then reading it). Import your function, pass it input, see what comes out; when it's wrong, you know what the problem is.

Debugging with prints is for stuff that isn't pure, behavior that is outside the Haskell runtime system and thus can't be reasoned about. Which means you're using IO, which means you can take advantage of 'print' or whatever.

I'm not arguing that there are no ways to debug Haskell programs. My point was that the OP's phrase indicates at least basic familiarity with Haskell and debug printing might be the thing he had in mind writing it.

Haskell's not like other languages, where you have to build up massive unreadable piles of code to get anything done.

That's fanboyism. I understand you feel offended by the OP's post, but it is not a good satire unless it offends somebody, and IMO, the article is excellent in summarizing attitudes of some members of the Haskell community. ;)

You absolutely can, if only you're willing to break the rules. :)

(Note that this does NOT break referential transparency as long as you're not dependent on the program's debug output for correctness of the rest of the program.)

    include System.IO.Unsafe (unsafePerformIO)
    include Control.DeepSeq (deepseq)
    
    (unsafePerformIO $ putStrLn "OES NOES") `deepseq` doStuff

VVV EDIT: blocking would also block doStuff owing to the deepseq, which means that your program might take longer to complete but will either return a consistent result or none at all. Similarly, if it causes an exception, at least it won't have failed silently. Moreover, none of these complaints are any worse than those you'd find in another language and both cases are esily detected (i.e., you immediately know when referential transparency is broken), so it's still fundamentally safe as a debugging aid.

Let me state that another way: if there is no evidence that putStrLn fails, the result of the above is identical to the result of "doStuff" alone.

(Anyhow, upvoted your comment because your statement is certainly correct, even if I claim it doesn't invalidate my initial claims about debugging :) )

Even assuming independence from the debug output, `putStrLn` may fail or block, which breaks referential transparency.