An amusing analogy, sure, but I can't help be reminded of this xkcd http://xkcd.com/568/ - "you'll never find a programing language that frees you from the burden of clarifying your ideas". Haskell just makes that trade-off more 'up front'. Obviously it's not the right tool for every job mind, of course sometimes quick and dirty scripts win.
Well, sure, but frequently I don't want to clarify all my ideas up front. I want to dip my toe in and see if my ideas have any legs at all. (Wow, tortured metaphor.)
I actually like Haskell. But I do think it's the wrong tool for a lot of the work that people here on HN tend to do.
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