16

Does anyone have a good mental model or metaphor for functional programming which references something in the real world?

Object Oriented programing intuitively makes sense to me. There are things that have properties and sometimes they also can do stuff or perform calculations on their properties (methods). (Ex: Car, Shape, Cat).

I bear functional programming no ill will whatsoever and I am not interested in a debate about the virtues of the two. I just need a metaphor or mental model to work with as I have with Object Oriented programming.

What are some good mental models or real world metaphors for programming in a functional paradigm? There is something about functions composed of functions processing functions which leaves one without a firm place to stand and cogitate.

gnat
  • 21,442
  • 29
  • 112
  • 288
Guido Anselmi
  • 292
  • 2
  • 8
  • Which concrete meaning of "functional programming" are you referring to, "no side-effects/declarative" or "first-class functions/function composition"? Or both? – acelent Jun 18 '14 at 17:09
  • Interesting question. With my current small knowledge of, and little experience programming in, "functional programming," I cannot meaningfully answer that question. If I were to hazzard a guess, I would say both. – Guido Anselmi Jun 18 '14 at 19:19
  • 13
    The "real-world" model is often given as a motivation for object-oriented programming. I think it is an approach you should eventually outgrow, because objects in OOP should not always correspond to real-world objects, and even when they do, the correspondence is often incomplete; for example, the "is-a" relationships are not always the same. On the other hand, once you say that you want a model or metaphor for a programming language based on something in the "real world", I think you have essentially restricted yourself to this limited form of OOP. – David K Jun 18 '14 at 21:15
  • A really good mental model, if you have experience using unix-like systems (or the powershell in modern Windows) is shell one-liners. They're not exactly the same since shell pipes is technically flow-based programming instead of functional but they have the same "feel" as a programmer. – slebetman Jun 19 '14 at 07:17
  • 1
    Also, you'll find as you learn functional languages, in functional programming object-oriented is treated as a tool, like regular expressions for example. Something you can use if you like but you don't have to. In some languages like lisp and tcl and forth OO is not a feature built-in to the language but a library that you can use (or you can even write your own OO if you feel brave). So problems that naturally have an OO solution can be solved using OO in most functional languages. People just don't treat OO as a religion. – slebetman Jun 19 '14 at 07:20
  • I need a cat that does calculations. – Jesse Millikan Jun 20 '14 at 02:45

8 Answers8

32

Functional programming is all about gluing smaller functions together to achieve your results. A decent mental model (for me, at least) is an assembly line. Each function that gets composed is one more step in the assembly process. Consider this function here:

smallest  = head . sort

In Haskell, this function will return the smallest element in a list. The assembly line first sorts the input, then returns the first element (assuming it's sorted least to greatest.) If we wanted to only get the smallest even value, then we can change the assembly line to look like the following:

smallestEven = head . sort . filter even

It's just one more step on the conveyor belt.

In a nutshell, functions just describe the steps taken to convert the raw input (the parts) into the processed good (the output.)

bstamour
  • 1,239
  • 9
  • 8
  • This is helpful. Is it good practice to think of functional programming in this linear way? I guess assembly lines could also have branching logic....But the idea is that there are a series of functions which occur. What about parallelism? Can one assembly line affect another? – Guido Anselmi Jun 18 '14 at 15:10
  • 2
    In a pure functional language with no global variables, then one assembly line cannot affect the other (unless it's feeding the other line input.) Theoretically any assembly lines that do not depend on one another can be executed in parallel, but I'm not sure if any compilers do this. – bstamour Jun 18 '14 at 15:12
  • It also would seem to beg the question of the intermix between OO and functional as OO could similarly model an assembly line (something like an assembly line of 'Command' patterns e.g. the 'Chain of Responsibility' pattern). What are the distinguishing features of the functional way of thinking about an assembly line? – Guido Anselmi Jun 18 '14 at 15:14
  • I would say the functional way of thinking might be better at modelling how data flows through a process. Instead of assembling objects and method calls, like in OOP. The thing about metaphors though is they can only take you so far. At the end of the day functional code is functional, and OO code is OO. *shrugs*. – bstamour Jun 18 '14 at 15:18
  • Thanks. Best metaphor I have heard so far! And I appreciate your modesty. Much ignorance is created by over statement! I appreciate your restraint. – Guido Anselmi Jun 18 '14 at 15:22
  • 3
    @GuidoAnselmi One way to think about it is that the assembly line in functional programming builds new outputs while leaving the inputs intact, whereas the assembly line in traditional OOP transforms the input. – Doval Jun 18 '14 at 15:24
  • You're welcome. Glad I was able to help. – bstamour Jun 18 '14 at 15:24
  • 2
    This metaphor only makes sense in the "first-class functions/function composition" meaning of "function programming", not in the "no side-effects/declarative". Also, object-oriented programming doesn't necessarily have side-effects, so you can implement either a destructive or constructive assembly line with either OOP or this meaning of FP. OOP is more about encapsulation, message passing and polymorphism than it is about side-effects, it depends on how you model things. E.g. do you require referencial identity from start to end? – acelent Jun 18 '14 at 17:40
  • @PauloMadeira Functional programming has encapsulation and dynamic dispatch as well, and most OOP programmers write imperative code, so in general I find the distinction based on encapsulation to be rather bad in practice. – Doval Jun 18 '14 at 18:08
  • Curious: can I infer from your example that in Haskell "things flow left"? Meaning that execution starts at the right end of the statement and results of the right most function are input for the one to its left? That would present an interesting challenge for someone used to OO fluid coding where each method of a class returns the instance it worked on as its result (including its now changed state), which means that "things flow right". Meaning that in fluid coding your examples would become `smallest = SomeInstance.Sort.Head` and `smallestEven = SomeInstance.FilterEven.Sort.Head`. – Marjan Venema Jun 18 '14 at 19:45
  • Good catch: yes, the dot operator applies the second function before the first. The same way that `f . g` typically means `f(g(x))` in mathematics. – bstamour Jun 18 '14 at 19:48
  • 3
    @bstamour: To be precise, one should write that `(f . g) (x)` means `f(g(x))` or `f . g` means `\x -> f (g (x))`. – Giorgio Jun 18 '14 at 20:49
  • 1
    Nice mental model that of an assembly process. +1. When I use a functional language I often think about playing LEGO: putting small, independent pieces together to build something complex. – Giorgio Jun 18 '14 at 20:59
  • 3
    @MarjanVenema Things flow left in that example *only* because that's how `.` is defined; this isn't how Haskell works *in general*. You could just as well define F#'s forward pipe operator (`|>`) in Haskell and write `smallest x = (sort x) |> head` and the data would flow right. Just thought I'd point that out. – Doval Jun 19 '14 at 19:34
  • @Doval: Thanks for taking the time to explain. Learned something :-) – Marjan Venema Jun 20 '14 at 10:13
19

Does anyone have a good mental model for functional programming?

Mathematics. Functional programming is inspired by and modeled on mathematics. Mathematical functions don't have state, don't have side effects, etc., and so it is with FP. If you think about FP in terms of mathematical functions rather than using an OO-style "how do I do this to that" approach, you'll be in good shape. If you try to bring OO sensibilities to FP, though, you'll be swimming against the current.

Caleb
  • 38,959
  • 8
  • 94
  • 152
  • 1
    Thanks. However, I need a metaphor from the real world (e.g. not from computers or mathematics). – Guido Anselmi Jun 18 '14 at 15:01
  • 4
    @GuidoAnselmi: A function is a black box. You put something into one side and then something new comes out the other side. If you put the same stuff in, you always get the same stuff out. You can take lots of these little boxes and combine them in different orders to build a factory that might take in raw metals and output a car. Inside the process is broken up into lots of pieces, but from the outside it's just another function. – Daenyth Jun 18 '14 at 21:38
16

How about a flip book?

In a flip book each page represents the world as it exists at a moment in time. In our program the world is represented as some compound data structure (e.g. we have a banana which is in the hand of a gorilla which is in a tree which is in a jungle). Each subsequent page advances the story by slightly modifying the previous representation. In FP, persistent data structures were designed to efficiently reuse previous structures so that a change provides only a delta and not a completely new rendition.

What may not be obvious is that a page in our flip book would also represent intangibles. For example, if the gorilla drops the banana we might start applying the effects of gravity on its decent and acceleration toward the jungle floor. To accommodate this we'd attach attributes such as velocity and trajectory to our banana.

In our program there would be a function that accepts a flip book page (a.k.a. the state of the world) as an argument and yields a new page. In this manner our story is told without ever actually changing the state of existing objects. We simply supersede each page with a newer one using what is effectively a calculation.

Mario T. Lanza
  • 1,700
  • 1
  • 13
  • 22
3

Relationships.

Friend: Given two people, a friend relationship follows these general laws

  1. Have good will towards each other
  2. Thinks each other are a friend to them (so the laws must be fulfilled by both members in this relationship)
  3. Enjoys spending time with each other

Monoid: Given multiple items and a function that takes 2 of the items and returns 1, a monoidal relationship follows these general laws

  1. There is one of those items (only one, called identity) which passed to the function with any other item will ensure the function always returns the other item (0 + 1 = 1, thus 0 is the identity when the items are numbers and the function is addition)
  2. The function cannot operate on or return items not in the set it has a monoidal relationship with
  3. The function is associative and can be used with the items in a somewhat order independent manner, this means a * (b * c) = (a * b) * c which says you can multiply a by the result of b*c or c by the result of a*b and the result will be the same whichever you do first.

Functional programming is all about generalizations, friend is a very general relationship that can be seen in numerous scenarios, but in all various formats it generally follows the laws above.

Recognizing the laws that governs the relationships between things, you can create general implementations that work on any format of things that has that type of relationship. In functional programming you try to identify the relationships between things so that they can be classified and treated generally.

You want a metaphor from the real world? Look at how things are related and try to identify general laws (as in applicable to multiple scenarios where things other than the laws may vary). There is a relationship between a register clerk and a shopper at a store, it has some general laws, software has been developed to facilitate the goals of people in that general relationship in the way of POS systems. Similarly when you start seeing these general laws dictating how things are related, you can start relying on the laws of those relationships in writing your software rather than the specific particulars of an instance of a relationship.

Jimmy Hoffa
  • 16,039
  • 3
  • 69
  • 80
2

Everything's a value, and you apply functions to values (which may be functions) to produce new values, preferably without producing any side effects.

Doval
  • 15,347
  • 3
  • 43
  • 58
  • Thanks. Unfortunately, that sounds more like a description then mental model or metaphor. I need a metaphor from the real world (not from computers). – Guido Anselmi Jun 18 '14 at 15:00
  • 1
    As [Caleb points out](http://programmers.stackexchange.com/a/245385/116461), functional programming models mathematics, not the real world. It can model the real world through the lens of mathematics, but you likely won't find a metaphor that satisfies you, because FP shuns the concept of things with a persistent identity and mutable state. If you like, I can point out how OOP constructs map to FP, but that still won't be the answer you want. – Doval Jun 18 '14 at 15:05
  • But mathematics is based on the real world. 1 sun, 9 planets. 2 apples plus 2 apples makes four apples. – Guido Anselmi Jun 18 '14 at 15:06
  • And in functional programming you can also have a type for suns, planets, and apples, then create one value of type sun, 9 values of type planet, and define addition for the apple type. – Doval Jun 18 '14 at 15:08
  • 3
    @GuidoAnselmi you have it completely backwards, people analyze the real world with mathematics, it has no basis on the real world. Mathematics is used for analyzing and defining relationships between all sorts of things, real and not. 9 planets is you applying a mathematical construct (the set of natural numbers) to a real world construct (planets) with a mathematical analysis function (count). The real world doesn't have 9 planets, it has what it has, math merely talks about symbolic representations of things wherein the symbols have relations between eachother. – Jimmy Hoffa Jun 18 '14 at 20:22
  • @GuidoAnselmi: I wouldn't think that way. Nature is an approximation of mathematics, not the other way around. There's no such thing as infinity in nature, for starters. – mike3996 Jun 19 '14 at 06:48
1

The key thing thing to realize about functional programing is that everything is a value - even the code itself is 'values'.

The best example of a simple functional programing environment is that of everyone's favorite business tool - the spreadsheet. Every cell in the spreadsheet is either data, or the result of a function. Whats more, this function can't go off and modify another cell.

When one moves to a functional languages, instead of a Cartesian grid of A1 and B42, the functions have names. That's all it really is.

There are other aspects that one can add on beyond this... but that's functional programing at its core. One needn't worry about the structure of lists or the grouping of things. Functional programming is about passing a value into a function and getting a value back without having any mucking about elsewhere in memory.

Thats it. Functional programming is a spreadsheet with names rather than a grid.

0

You can think of functional programming as about behaviours. A program is a description of the behaviour that you want the computer to enact. Functions are the basic unit of behaviour, and function composition is one way to build larger behaviours out of smaller ones.

In OOP, a code object is intended to be the state of an object in the problem domain; it changes over time to reflect changes in that domain object. In FP, a value represents the state of a domain object; it never changes, you simply create different values to represent different states.

I find the functional model a bit more honest about what computers are actually doing—representing. After all, I can’t just conjure a new Tesla() out of thin air. :)

Jon Purdy
  • 20,437
  • 7
  • 63
  • 95
-5

Sentences are more functional than object-oriented, assuming you break them down more or less like the following...

The brown cow is in the meadow across the deep river.

So we need to find the head phrases and then the rest:

The cow (brown)
the meadow (across)
the river (deep)

In one go:

sentence: The cow ((the meadow (the river (deep)) (across)) brown)

Parse tree:

|                     sentence
|                      /         
|                  The cow
|                 /       \
|            the meadow   brown
|            /         \
|      the river      across
|              \
|              deep

Parsimony infects functional thinking;

Hats off to Gottlieb Frege 1890s, Alan Turing (entschiedungsprobleme) 1930s, Noam Chomsky (1960s).

KTys
  • 1
  • 1