Because the entire programming model breaks down at I/O. When you have to compromise the language's _raison d'être_ to perform a basic function of the computer, the cognitive dissonance is real.
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.
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.
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.
