First: You're not stupid. FP advocates sometimes take the stance that you're stupid if you don't use FP, but that's a "them" problem, not a "you" problem. <i>You're</i> not stupid. If they can't explain it to you, either they're lousy at explaining, or FP is as clearly superior as they claim it is.<p>I think that FP matches how some people think - and <i>doesn't</i> match how some other people think. When people that it fits learn FP, they have this "aha!" experience. They think if you don't get it, you just haven't learned enough to have the same experience. But in doing so, they are assuming that everyone else's mind works the same as theirs does. I think that's a false assumption. And I think it plays into the "we're obviously right, and anyone who can't see it is unenlightened/stupid" smugness that FP advocates sometimes have.<p>Here's what I have gleaned from various HN discussions in the past:<p>If you can think of your program (or a part of it) as a pipe, then FP is likely a good fit. If data comes in, gets modified, and goes out, that's a decent match for FP. And if it is, that has some real benefits. Pure functions (ones that are <i>only</i> a function of their inputs) are easier to write, debug, and use than non-pure functions are.<p>But, as someone said here, "real programs have state". Your program often is not just a pipe; there's some state somewhere. In some cases, the state predominates. (This is often the case for OSes and embedded systems.) What are you going to do with the state? In procedural programming, you put it in a global somewhere. In OO, you put it in a class somewhere. In FP, you still have to put it somewhere. FP sometimes does some jumping through hoops to make it not look like you're dealing with persistent state - but you still are, even if you wrap it up in something.<p>If you add multithreading, this gets far worse. FP is absolutely right that shared mutable state is evil, but if it's necessary for the program you're trying to write, I'm not sure that FP has a good answer. In OO, you put it in a class and protect access with semaphores. In FP, I'm not sure how you handle getting the newly updated state to the multiple threads that need to see it.<p>So FP isn't "better". It's a better fit for some problems (and some programmers), and a worse fit for others.<p>All that said, in an interview, if they're a place that uses FP, and you're not an FP person, then it may be valid for them to dock you lightly for that.