One of my professors used to say that functional programming makes all problems equally hard. There's some truth to that. For example, for I/O, most functiona

One of my professors used to say that functional programming makes all problems equally hard. There's some truth to that. For example, for I/O, most functional languages fall back on imperative idioms. Those that don't (Haskell, mainly) basically tell beginners to pretend that this weird thing (I/O monad) is just an imperative code block. You can figure out how it works once you're more familiar with the language. Since doing I/O is a pretty common task, functional languages generally include imperative constructs to fix this, but these constructs generally feel tacked on. The main drawback I see in practice is that functional programming can encourage people to be more clever than they ought to be. In the worst case, you can get some of the worst Java-like issues, where there's a function that returns a function that returns another function that actually does what you want, even if it's only used in two places anyway. In a more typical case, you'll get someone who likes to unnecessarily write everything in continuation-passing style, or jumps through hoops to move recursive calls into tail position even though the recursive depth never exceeds 5. If the team has the discipline to just avoid that kind of thing, the only real downside I see is being farther from the hardware.