In general if you care about performant code, you're going to want to write ugly imperative code. Sarah Groff Hennigh-Palermo has an excellent talk that explores FP vs imperative programming in terms of performance: thestrangeloop.com/2017/adventures-in-the-vbuffer…

In practice, I've found codebases written in imperative style more difficult to maintain, read, and change (they may appear to be easy to change at first).

Codebases written in functional styles are easier to read, harder to write, easier to maintain, and easier to change. There's also typically less code. I've also seen functional codebases over-engineered with unnecessary indirection, but that's not a critique of the style; I just feel like I need to note that FP isn't a panacea.

It's definitely easier to write in an imperative style when first wrestling with a problem. I find that I usually write my first draft imperatively and then iterate until I've got a nice functional solution. Functional code at its best reads like a poem that describes the problem it's solving.

It's like after applying the best practices (SOLID) to your OOP. blog.ploeh.dk/2014/03/10/solid-the-next-step-is-f…

I recommend watching this talk too: youtube.com/watch

Functional programming employs a model of computation called the lambda calculus whereas imperative programming uses the Turing Machine as its model of computation.

Whereas in an imperative language you allocate variables to hold values and then manipulate those values to compute a result (if you know what a Turing Machine is, imagine the head moving back and forth reading and writing values to the tape), with lambda calculus the function forms a boundary around logic. You can only interact with the system by passing values into a function and receiving the output. Therefore a lambda calculus is predictable: given the same input it will always produce the same output. It does not rely on any initial conditions outside of its inputs. It will also not mutate any other logic's state, so it is safe.

Others have already listed out what this means practically for functional programming, so I will leave it here for my explanation.

Honestly I don't think a few paragraphs can do it justice. The term isn't even very well-defined - are first class functions enough? No side effects / immutability?

Personally I feel that while writing functional style code - by which I mean using passing functions as parameters and avoiding side effects - that can be help in most languages. But it offers a lot of guarantees that are really powerful if you can actually rely on them, which you can only do (imho) if a compiler verifies them. So I'm the die-hard that Jason Knight talks about, I guess.

Anyway, I would recommend to read a somewhat longer description of it. I am not very qualified to explain, and this answer would get way too long if I were. But a summary:

• Easier to reason about because no side effects (e.g. you know a value hasn't been changed because it's all immutable, and you know setting X does not affect function F because it's not an argument)
• Easier to test (same)
• Easier to formally prove correct
• More declarative: what you want instead of how to do it
• Easy to parallellize because there are no side effect so different paths cannot affect eachother (in fact sometimes the hard part if not parallellizing too much) - and parallellism is getting more important
• Enables a lot of optimizations, such as caching function results (since the result can only depend on the arguments)
• Often easier to add functions to classes of objects (but harder to add types)
• Can (optionally) do things like lazy evaluation, because there are no side effects
• Often very high level

The main downside being that things that do use side effects can get really complicated, like reading files. It's also far removed from how hardware works, which is sometimes a disadvantages but usually great.

Depends on how it is used, and how it is abused/misunderstood by extremists.

Far too often the die-hard advocates of "functional programming" end up taking a decent concept into extremes much akin to Java's "Everything is an object". Making endless pointless extra functions for stuff small enough and simple enough it doesn't warrant a function, and WORSE using a function actually results in slower code!

This is particularly true when recursion is the core of implementation, since you're increasing the stack use, creating memory thrashing, moving extra data around, and just plain creating unnecessary overhead.

But again I learned machine language four decades ago before I ever touched a single high level language, so avoiding stack use and 'far' calls to make faster code is in my blood.

It doesn't help that IMHO so much of this 'functional' code is illegible gibberish that belongs more in a calculus class than in programming. The type of stuff where someone went "you know, C isn't nearly cryptic enough, what can we do to make this code even more obfuscated, but still dupe people into using it?"

I mean, there are some good ideas and sound concepts, but it seems like people are taking it to ridiculous extremes resulting in lousy performance and illegible code.

• Easier to test
• More reusable code
• Easier to understand on a micro level

More Info

Functional Programming

My Answer

As stated in Wikipedia. Functional programming is more so a programming paradigm than a programming style. Functional programming should be used in situations that call for it.

Generally speaking, functional programming is useful for applications that require specific functions that have predictable input and output.

The main advantages are as follows

• Functions can be tested for higher degrees of predictability.
• Functions can and should be reused as to not violate DRY .

I will leave you to read the wiki article on this as it does a much better job of describing functional programming than I will.

Cheers.