I did not have to deal with bad Haskell, yet. But I wonder, how it would turn out. The type-system can give you some pretty strong guarantees (if you abstain from using back-doors), and thus make interfaces much less leaky. I.e. if a function has the type String -> Int, you know that it takes a String and gives an Int, and doesn't have any strange side-effects, like setting some random variable or sending away your credit-card data.

Bad Haskell usually involves poor type abstractions, eg. instead of defining new data types for inputs that are logically distinct but physically identical, you just re-use existing types and add new constructors. Or you end up using tuples for everything. Or (horror!) you encode a bunch of things as strings instead of using the type system at all.

The nice thing about Haskell is that it's really, really hard to write things that accidentally ignore purity, which eliminates a whole class of errors and bad designs. The type system only helps you if you let it, though.

Yes, that's sounds plausible.

I've looked at a friend's Haskell program for Huffman encoding, that used raw recursion in a undisciplined way instead of abstracting the control flow out into, say, filters, folds and maps. That was the closed I ever got to ugly Haskell.