

We need functional programming because a large subset of us are average or below - wfaler
http://recursivity.com/blog/2014/09/21/we-need-functional-programming-because-most-are-average-or-below/

======
wereHamster
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.

------
mcx
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?

~~~
fegu
The functional version would chain these statements (either implicitly with
temporary variables or explicitly with bind), so it became obvious which
depends on which.

As it is now, you can't be sure if foo.setBar(bar) changes bar, and you can't
be sure if dao.update(foo) changes bar. You also can't be sure if foo is the
same before and after addBar.

Imagine coming back two years later to add some functionality here. You can
either read all the other functions or you can rely on the choice of verbs to
guess. In functional code, you won't have to guess (as much).

