It seems to me that the author is confusing what the actual point of FP is. I do not think it is about writing less, more concise or more understandable code: t

It seems to me that the author is confusing what the actual point of FP is. I do not think it is about writing less, more concise or more understandable code: the examples they bring are of different length mostly because they use languages with different abstraction level, which is largely independent from being FP or not. The first snippet (the assembly one) requires to use a whole line for each single sum; the second one has a built-in concept of lists and iterations on lists; the third one allows higher order functions. This gives different lengths, but the point is not FP. Neither it is true that FP guarantees more readability or understandability, which actually depends a lot on what your are used with. If you are used to imperative, FP will probably be a real pain. It is not even true that shorter functions are in general more readable the longer ones: I can immediately understand pages of code and struggle on two lines, depending on what they do and how they are written. The actual point of FP, as I see it, is that it decouples a function from the context it is executed into. A pure function is not influenced by its context (the global status) and does not influence it (it has no side effect). Actually, for a pure function the context does not exist. So if you want to read or understand it, you can ignore the context; and viceversa you can ignore the function when studying any other. The only interaction between different functions remain the explicit calls, which are easier to track than the implicit coupling given by the global context. So that is the advice from FP that I would give to every programmer: when writing a function, try to use the global context as few as possible, possibly even not at all. All the other stuff with lists, zipping and lambdas is fun and useful, but it is not the real heart of FP.