[mightybyte]

To me this argument isn't much different than saying "why do programmers see it as a good thing to package their code in abstractions?". There will be difficulty of participation for all non-trivial projects. Every substantial project builds up its own unique abstractions, and you have to learn them to contribute. I see this as an unavoidable fact of building complex systems.

I really don't see a meaningful difference between the more syntactically varied abstractions in Haskell and the more wordy abstractions you see in OO languages (like FooFactoryProxyBean). It's still something new that you have to learn. You're just not as familiar with the way people do it in Haskell. If you had never seen the terms factory, proxy, and bean before, you'd have exactly the same complaint that you have about Haskell abstractions.

Where Haskell possibly does differ is in the level of abstraction it can achieve. Some of the abstractions haskellers use are significantly more abstract than what you typically see in mainstream languages. Sure, it will be more difficult for a newcomer to comprehend. But in return we gain a lot of power and expressiveness that you don't get otherwise.

Oh, and to my knowledge Gabriel's "method notation" is not actually in use in real code. It seemed like more of a convenience notation he introduced for the purposes of that post. That kind of thing is pretty common in academic literature. And if it is being used somewhere, it's definitely not mainstream Haskell.