And often, there is no natural name for a function that traverses multiple control structures. The denotation is the most informative name. What would you name a function that lifts a function into two nested functors, is partially applied, and is then lifted up into another functor? This kind of stuff happens quite a bit. And my code is easy to read, because nearly invisible glue code connects two concepts in a relationship that makes sense (typically in terms of products or direct sums implemented via functors).

Consider the expression: (num_shirts_in_factory_a + num_shirts_in_factory_b). Which parts of that expression are the informative ones? Obviously, it is the "num_shirts" variables. And there is only one "sensible" way to put those quantities together. Now push this idea to its limit. It is more than there just being one sensible way to write glue. There is exactly one glue function between glue-able types.

On the other hand, I have used some type classes to move some of the more repetitive glue away. I have classes like:

class Monic a b where inject :: a -> b -- to represent monic morphisms
class Epic a b where surject :: a -> b -- to represent epic morphisms

You can easily have a class like

class Glue a b where
glue :: a -> b

and hide all the line noise in there. And then your client code will look like

blah :: StateT (MaybeT IO) (Integer) (Maybe Integer)
blah = glue . parseInt . glue . getLine
-- or
blah = glue $ parseInt $ glue $ getLine

This is how "line noise" glue code looks to me. Except line noise is more maintainable. *fnord* Note that these glue functions would each require their own distinct type class instance.

The nicer the client code looks, the more complexity you have to shovel into the Glue instances. But you are merely transferring complexity -- not creating or destroying it. Complexity is created by data type definitions being glued. There is the potential for a combinatorial explosion, since you can have unused Glue instances, whereas you cannot have unused "line noise" glue code.

Mathematicians don't care about mathematical symbols. They care about the things the symbols join, because the semantics of joining "things" is dependent on -- and usually determined by -- the things being joined.

While this seems superficial, it´s quite important in the industry. Guess why Cobol had the syntax it has and why Javas "elaborate" syntax is considered a feature. Naming stuff is better than using strange symbols if big teams work on big code-bases - thats the main reason Java still hasn´t operator overloading.

Haskell has been designed as a language for programming-language-reseach. In this area free definable operators are a good thing because it allows to try out interesting things without having to change the parser of the compiler. But for industrial use, it´s a very dangerous feature.

If it's merely just as productive as what people are already familiar with, or pretty close to it, there's no reason to switch.

4. When I for one whip out the "monad is a monoid in the category of endofunctors" comment, it is mostly with my tongue firmly in my cheek, unless I'm talking to someone else who has spent a lot of time fiddling with category theory. My blog is filled with particularly egregious examples of this sort, but I make no claims that it is a gentle introduction, merely a smattering of things I want to talk about.

6. I have never had difficulty meeting my demand for Haskell programmers and the ones I have hired have been among my best employees.

7. Talking to an (XML-) RPC server: http://www.haskell.org/haxr/ There are also several others.

7. Lack of windows support: yes this is definitely a big deal. In the Haskell community's case, there just isn't much of a user base there building things. Yes, this goes back to your previously mentioned recursion principle, but sadly, it is an artifact of the current user base. The Platform, however, builds on Windows and is growing to encompass more and more of the core functionality you would expect out of a language with 'batteries included'.

8. Isn't a problem if you take the time to grok strictness annotations and explicitly unpack structures that will obviously be used with high frequency. These will help address space leaks, which cover the worst performance issues.

w.r.t. Embedding: The old [Request] -> [Response] driver was an 'initial algebraic encoding' of the problem. On the other hand, IO is 'final'. They are equivalent systems. You're mistaking arguable issues with there being too many assumed trappings in the existing platform for embedded systems work for the mechanism used to implement those trappings. If you're turning to an ADT to express a language you're probably using the wrong tool (See "Finally Tagless, Partially Evaluated").

As to your overall conclusion? I happen to disagree, but wanted to stick to quantifiable issues.

Are FP and OO fundamentally incompatible? If Haskell's type system is so superior, how does one actually make the transition from an OO mindset, and how does one approach complex domain modeling problems in Haskell? Where are the case studies in how this benefits industry? I still haven't seen this addressed from the Haskell community... though I have seen lots of academically interesting concepts come out of it.

My latest attempt at boiling it down is to say that Darcs performance is about three things: (i) theory, (ii) engineering and (iii) implementation.

Theory means the core theory of patches which makes Darcs powerful and easy to use... until you hit a conflict. Simple conflicts are fine. When conflicts nest, however, you do get a combinatorial explosion of nested "merger" or "conflictor" patches. The darcs-2 version of patch theory obviates a lot of this nesting, but we still have a lot of work to do on the theory end. Haskell is irrelevant here.

Engineering refers to high-level choices about how we store information and ship it around. Darcs performance has been improving a lot in the last two years because we have been emphasising the engineering aspect of things. For example, we use timestamps to determine if we need to check the committed and working copy of a file for differences; however, because we also use hard-links to save time/space, the timestamps from the filesystem can mislead Darcs into checking for way more differences than it needs to. Recent versions of Darcs use an index file to store our own timestamps. Another example of work we are doing in this line is to "pack" our many small files into fewer larger files that we can transfer over HTTP a lot more quickly.

Implementation can include choices like Haskell as a programming language. The last time I tried to clarify this, I said that Haskell doesn't make a difference here. Thinking more about it, I realise I was likely wrong. Sorry! One place where Haskell *could* make a difference is that we have a number of performance bugs we have open where Darcs seems to be using an unreasonable amount of memory for the task at hand. It's not yet clear to me if these are actually engineering bugs in disguise, or if some of them are not merely implementation details. The Darcs team is quite small; we need all the help we can get. Once we've reached a couple of engineering milestones we have in mind, it'd be really great if the wider Haskell community could give us a hand on understanding these bugs.

Meanwhile, I still have the conviction that solving a lot of the engineering issues (Darcs 2.5 and 2.6 look very promising) will make Darcs a lot faster for most people, most of the time. We still need to work on theory and implementation over time, but I hope you'll like what we've accomplished for the short term.