Let’s try rewriting your example this way
add = function(a,b) { + a b }
Why is this better? Because + is a function, and add is an object, so you can then refactor the code to say this
add = +
Try doing that in C.
As I see it the code for some programs has a high degree of symmetry (ie repeated patterns), and the best language is a notation the let’s you capture that the best.
If you find yourself cutting, pasting and modifying things slightly each time, then your language is holding you back.
Test-script code is the best example of this…particularly hardware tests. You have the same code copied and pasted dozens of hundreds of times.
Thoreau once said that government is best that governs least. That language is best that makes you type the least.
Function pointers. They are abused to no avail in C programs. It has the original callback hell, not JS. (And that is mainly because C has no proper way for abstractions)
Your example is strict FP, where a and b are fully evaluated before add() executes. There's also non-strict FP, where everything uses lazy evaluation by default. That has some big advantages but also a few pitfalls, and generally makes things significantly weirder when compared to imperative languages.
Pure FP is where you only have functions and expressions, no variables at all. I think that's where most mainstream programmers draw the line -- sometimes you just want to store something somewhere, without being forced to jump through what seem like weird hoops.
The original elevator pitch for Haskell was that it's a "non-strict, purely functional" language (aimed a unifying a bunch of different research languages, plus the proprietary language Miranda).
It would help if someone defined what constitutes "using functional programming".
I mean, this is functional programming:
From my experience, every developer does functional programming to a certain extent, it's just the extent that varies.