**3 + 2 = 5**

can there be two ways of looking at that?

Turns out there are.[1] One can see = as equivalence, which means that

**5 = 3 + 2**

is the same statement.

Or, one can read = as “results in”, seeing “the operation of adding 2 to 3 yields 5.” In this case,

*5 = 3 + 2*

is meaningless and backwards.

It turns out that children learning arithmetic often think of equals this way, as a “results-in” sort of statement. Like:

*flour + water + sugar + eggs + mixing + baking = CAKE*

*Buy 2 Pizzas = Get One Free*

In most programming languages, the equals sign is closer to the “results in” meaning. The order is reversed, and we get

*a = 3 + 2*

meaning “the result of the operation of adding 2 to 3 is stored in a.” Then we can use one or more equals signs to test for equivalence:

*a == 5*

which is, again, an operation. Usually it’s the equals operator on a, with 5 as an argument.

Neither the child’s-arithmetic interpretation or the imperative programming interpretation have anything to do with the mathematical meaning of equals.

Why do we care? If you think back to algebra, where = very emphatically meant equivalence, that stuff was darn useful. You could figure out all kinds of puzzles with statements of equality. (Integrals were my favorite.) Order didn’t matter, and you could do whatever you wanted to both sides. This was deductive reasoning, real logic, in action.

This is where functional programming is trying to take us. “Don’t tell me what to do. Tell me what you know, and what you want to know, and we’ll get there.”

Moving from imperative to functional programming is akin to moving from arithmetic to algebra.

Like @runarorama said: “Code it functionally. Like an adult.” (That cracks me up.)

—-

[1]This comes from Surfaces & Essences, by Hofstadter