Yes, that's functional programming! I think you're right to say that many programmers use FP much of the time. The modern trend is definitely to borrow many FP techniques and use them inside an imperative shell.
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).
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).