I love functional programming. It’s great. While creating a few of its own small challenges, it helps to alleviate so many problems that we have in other styles of programming.
I love reading. Especially reading about programming. Especially reading about functional programming. What I don’t love is reading books where the author has his (or her, although I don’t think any of the programming books I’ve read were written by a woman) terminology wrong. Programming has a lot of big words in it, and functional has some that are kind of new to other types of programmers. To make sure you’re not mislead by an incorrect author, here is a small list of some words in functional programming. To be certain that I had it correct, I double-checked with wikipedia.
Higher-Order vs First Class Functions
This is one where I’ve seen the most confusion. The two are related, and in fact, one is a subset of the other.
Higher-Order functions are functions that either accept a function in the parameter list, returns a parameter, or does both. First Class functions always do both; they accept functions as arguments and return functions (typical Python decorators fall into this category).
Sometimes, people apply one of the previous definitions to pure functions, but that’s way off; a pure function doesn’t need to accept or return a function. It doesn’t need to even have a parameter list.
Pure functions do require you to return something, though. Pure functions are functions that fit both of these statements:
- When called with the same arguments, it always returns the same result. Not returning anything does not count as “returning the same result”, because having a function that doesn’t return anything doesn’t follow the next statement.
- There are no side effects, nothing mutated
I haven’t seen any incorrect definitions of a lambda, but I’ve certainly seen definitions that didn’t really say anything.
One thing to note about lambdas is that they’re anonymous. They have no name. They can be assigned to a variable with a name, but that doesn’t stop them from being lambdas. They’re a shorthand version of a function declaration, often called “function literals”; a name is not part of that declaration.
Also something I haven’t seen defined wrong, currying is in here because I don’t think a lot of OOP/FP hybrid programmers know about it. Nothing against those who don’t, since I’ve only ever seen it present in pure FP languages, and I’ve only heard about it from two different sources, despite all the reading about FP I’ve done. Due to it’s lack of use in hybrid languages, I can understand why most of my sources don’t mention it.
Anyway, currying allows you to partially supply parameters to a function so it can finish being filled in later. This is the same purpose that
partial fulfills in Python. Some languages use this as the only way to define functions that take multiple parameters. Passing in the first argument returns the function that will taking in the second argument, all the way until you’ve given the final argument, where it applies all the arguments to the function. Only syntactic sugar allows you to do it all in one step in code.
Currying is especially useful when supplying a partial function as a function argument. For example, if Python had currying, we could turn this:
def calculation(a, b): # some crazy calculation return result calc_five= partial(add, 5) result = map(calc_five, some_sequence)
calc_five = lambda b: calculation(5, b) result = map(calc_five, some_sequence)
def calc_five(b): return calculation(5, b) result = map(calc_five, some_sequence)
result = map(calculation(5), some_sequence)
You see how there was no intermediate definition needed? Technically, there wasn’t one needed for the lambda either, but inline lambdas look bad in Python (and some other languages).
calculation(5) returned a function that would take in the
b argument and apply it to the body of the function.
That’s my FP glossary. If you didn’t know this stuff before, I’m glad you got a chance to see it. If you did, I’m sorry if I wasted your time 🙂