I don't want to be excessively dismissive, but I'm curious if you have a more-precise explanation for why you think that Haskell's programming model "breaks down" at I/O? I'd say that one of Haskell's entire purposes as a research language has been exactly about modeling, reasoning about, and representing I/O and other sorts of effectful computation in the type system. Unless I've misunderstood you or there's something more subtle you're referring to, I don't follow what you're trying to say here.

This is what always fucked me up with Haskell. To introduce printf debugging, you get sucked into the morass that is the IO monad, and all the clusterfucking that involves.

You don't need IO at all for printf debugging. Just call trace or traceShow. https://www.stackage.org/haddock/lts-7.16/base-4.9.0.0/Debug...

Apparently things have changed since 2007... Or else my Ivy league CS professors didn't know what the hell they were talking about. As I grow older and more cynical, the difference between those options continues to narrow...

I wouldn't be surprised at all if Ivy league CS professors didn't have in depth programming knowledge. They are Computer Science professors after all, not programming professors.

If you're teaching a course in X using Y, I don't think it's out of line to expect someone to be proficient in both X and Y. That's kind of their job.

I recently finished a Linux course at school, part of which was focused on Vim. I got points taken away for using gg to jump to the top of a document and G to jump to the bottom. My professor said neither option would work. While I think it is reasonable to expect professors to know what they're talking about, it is fairly common that they don't.

Printf debugging is right there in the prelude: https://hackage.haskell.org/package/base-4.9.1.0/docs/Debug-...