We need functional programming because a large subset of us are average or below

I'm not buying it. Having worked at a company which did all their software in a purely functional language, I haven't seen any evidence which would support his points.

> You do not have to build a mental model of the whole system and its libraries to reason about it.

You have to build a mental model of the part which you are looking at if you want to reason about it. If you're looking at a single function, you need to build yourself a mental model of that one function. If you want to reason about the whole app, well, then you have to build a mental model of it all. The language you use doens't change that.

> Corollary, you can reason about any subset of the system, however small, without having to even understand what the whole system does.

That is true in any programing language.

In practice however this doesn't hold. You very often can't reason about the correctness of a single function without also knowing it's immediate surrounding code. or in which context it is used.

> You don’t have to rely on your memory of something you did possibly years ago to deal with new requirements, changes or to track down bugs.

Neither do you in any other language. Just follow the code. And: badly structured FP code is harder to follow than clean procedural code. FP alone doesn't buy you anything.

> For the managers out there: key-person dependencies (“the guy who knows everything about the system”) become less of an issue.

It is exactly the same issue as if you were writing the code in any other language. Having a single person who knows about a certain part of your application is bad. Functional language doesn't protect you from it.

The measure should be how long it takes a new person to get familiar with the code. Well-structured code written in any language should be equally easy to understand and follow. I've seen some really bad code written in a functional language. Here again, FP doesn't protect you from bad code or its consequences.

> New people can become productive much faster, no longer having to spend the time building a mental model of everything.

Any reasonably complex app will require programers to know about many aspects of the app. You can't make changes to one part without knowing what consequences it will have to other parts. This is especially true for logic-heavy apps.

A new programmer you just hired may have the impression that changing that one little knob in a small function there fixes the bug. But it may have to him unknown consequences because he doesn't know where and how that function is used, what pre/post-conditions the callers are expecting etc.

For the first example used:

  public void addBar(Foo foo){
      Bar bar = new Bar("baz");
      foo.setBar(bar);
      dao.update(foo);
      dao.save(bar);
  }

What would the functional version look like?