As others have said, immutability and referential transparency enable you to reason about your programs much more cleanly that you are generally able to in impe

As others have said, immutability and referential transparency enable you to reason about your programs much more cleanly that you are generally able to in imperative code. Functional programming also forces you to think about problems in a recursive manner, which is inherently very valuable, as the idea of solving problems by recursion is extremely powerful. Take a simple problem like this: given k different denominations of coins, how many ways can you make change for n dollars? (This is a problem from SICP, which also seems to come up on HN a lot). The functional code for this is about 10 lines. I don't even know how you would solve this imperatively... You may look at this example and think it's contrived, that "real world problems" aren't anything like counting ways to make change. But just because you haven't encountered it in your daily work doesn't mean that other people haven't, or that it's not valuable as a tool in itself. And ultimately, having conceptual tools for thinking about problems is always going to be a good thing. Btw, I find it slightly amusing that you don't want "to write programs like I'm writing on a Turing machine" since imperative programming maps pretty directly onto TMs as a model of computation...but I digress :)