Do arrows, monads, monad transformers clash when a large app needs libraries which use each of these?
Now for my question
from my neophyte perspective, Clean has a single easy-to-use mechanism for state maintenance - uniqueness typing.
Haskell has monads.
But then it also has arrows now.
And so there are two XML products, one based on arrows and one based monads.
When one is developing a large project in Haskell, what does one do if certain libraries are done in arrows and others in monads and you need to use both? And what about monad-transformers? Is that not yet a 3rd complication?
A Java programmer only has objects to handle any concept. So the idea of one library doing one thing and another doing another does not come up.
So, is there a difficulty in large application development because of the clashing advanced functional metaphors of arrow, monad, monad transformer?
Let's face it. There are very few large-scale products shipped in Haskell. Period. I dont know how good that is. or why that is.
I suppose Galois is happy with haskell, but the lack of large useable apps make you wonder if something like what I mention is getting in the way.
About my level and interest haskell
I have been through SJT's book. Been through the Haskell Road. Been through Sethi's "Algorithms". Like Bird and Wadler's intro to FP.
Now, I first got interested in Haskell in 2003. I love haskell. It is profoundly elegant. I never quite got over the hump into making it useful... 8 years as a Perl developer spoils you. But as a Perl developer, I think very functionally and studying Haskell has helped me immensely. But i always run back to my crutches when the game gets tight.