Friendly patterns and algorithms | Why isn’t Haskell popular in Industry?...

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.