Indeed; I'm used to writing systems software, so user interaction tends to elude me :).

That being said, I would dare say that the business layer is the one which would benefit the most from a FP perspective. I can think of dozens of bugs in my code that originated in my inability to correctly keep track of what was otherwise needlessly exposed state.

Being many layers closer to the silicon, I don't actually use any functional programming language for my work (it's C and Assembly all the way...), so I can't speak for using one. But applying some functional framework to my code proved immensely useful once I started doing it.

(At the risk of sounding like a hipster, that was actually before FP suddenly becoming cool. I tried learning Haskell once and miserably failed; I was only smart enough to learn some Common Lisp).

Indeed, many languages would benefit simply from having modifiers that reverse the typical use of "const". Make everything immutable / side-effect-free by default, and add a "mother may I" keyword that allows mutation / side-effects without giving a compile error.

Hopefully, programmers would learn to avoid writing code that requires the "stomps-all-over-shit" keyword except when they really did need it. (assuming tail call elimination for simple loops)

One of D's improvements upon C/C++ is its ability to enforce "deep const-ness".

Well, that's for theory. In practice I have yet to see a big CRUD like Facebook rewritten functional style, and would very interested to check how this magically dissolve the inherent complexity of such a beast.

Until then, I'd continue to think that functional is shiny and sexy but that the proven and pragmatic way to keep complexity in check is still the good old and boring oop way.

As other commenters have said the point isn't the eliminate complexity. Some problems are actually inherently or irreducibly complex! The goal is to find ways to manage the complexity. Abstraction barriers are a trivial example[0]. Type systems are another approach, hopefully foisting the complex management of datatype correctness on the compiler rather than the programmer.

None of these approaches necessarily make the problem itself less complex. But as with a type system there are ways in which a language can help, or hinder. A language which adds too much complexity incidental to the problem you're trying to solve is an example. TFA is groping towards this point, but they did a poor job arguing it.

The proposition is that a functional language's abstractions, conventions, and patterns may make it easier to manage (not dissolve) complexity. It's hard to argue that (e.g.) functions which are referentially transparent are easier to reason about, for instance. Whether this is more difficult in the large, as a project scales, is unknown to me.

[0]: http://mitpress.mit.edu/sicp/full-text/sicp/book/node29.html

I don't think anybody is claiming that functional programming makes complexity magically go away. The claim is that functional programming (especially when backed by a strong static type system) makes several categories of issues essentially disappear. That's a much more reasonable claim to make.

And a very powerful property. Never mind conserving CPU or memory; the slowest component in any system is the wetware programming the system: you. I always try to use tools and techniques that eliminate the possibility of categories of bugs. I use scope to control use-counting when possible; I use as strong a type as is helpful in the tool I'm using etc.