I think the basic issue most people have with Haskell (or rather, with Haskellers) is the fetishization of 100% correctness. For most tasks, it's just not that

I think the basic issue most people have with Haskell (or rather, with Haskellers) is the fetishization of 100% correctness. For most tasks, it's just not that important, and so the (considerable) extra cognitive load that Haskell imposes is a net negative. I mean, precise joinery may be superior to hammers and nails when building a house, but it's an expensive proposition, and there are 5 people in the world who can do it properly. Most of us monkeys, when coding, are aiming to accomplish some task in the notoriously incorrect real world. It is often much better to spend 1/5th the engery get to a 80-90% correct solution very fast, and then patch as necessary, for the very important reason that you don't even know if what you're attempting to do will work. In that mode, like carpenters, sometimes it's helpful to just bang it with a hammer. If what you do is write compilers, well, OK. The description you're quoting sounds pretty good. But the world doesn't need tons of compiler writers, and those it does need typically have pretty stable specs in front of them, so maybe joinery is the right approach. I think this guy gets it about right: http://alarmingdevelopment.org/?p=440 http://alarmingdevelopment.org/?p=440