Abstraction, like optimization, is nice when it serves a purpose. If it doesn't serve a purpose, you're probably just making your program harder to understand for no reason. You can see this in Java too, with proliferating class hierarchies introducing needless concepts. Haskell is also a research language and there are people working on abstractions for the sake of it, much like mathematicians sometimes do. If that's not your interest, just write programs that work and don't worry about being abstract for the sake of abstraction!

> ...fear that my program isn't abstracted far enough...

This. I feel exactly the same. I read various concepts like Free Monads, I go find papers and read them. But when I sit down to write code, my code is a blob doing IO. I can use State monads, StateT etc. But the result is not the elegant programs that I see on books and blog posts.

I am also very pragmatic. I want to build tools that implement an idea I have. I want to build as soon as possible to try these ideas out. But when programming in Haskell, I find myself code golfing and lost in the means rather than the ends.

That captures my feelings really well. And then I think that if I'm going to stick to the "meat and potatoes" of functional programming, I might as well just use a language in the ML family.

Except controlled side effects are a godsend, even for meat and potatoes.

Yes, indeed. Even with the 101 level haskell I write, it feels so right. I exactly know where the side effects are and the semantics of the program is so clear.

That's why Go succeeds too.

Are you really talking about ghc extensions? I think it's quite possible you'd feel that if the haskell library state of the art just had advanced in a strictly haskell-98 world.