
Programming may one day be about getting the maths right - turoczy
http://www.irishtimes.com/newspaper/finance/2011/0429/1224295670955.html
======
Tiomaidh
Misleading title--if nothing else, it should contain the words "functional
programming".

And IMHO, a very misleading analogy (object-oriented programs : cake recipes
:: functional programs : equations). Programming paradigms really have no
real-world counterparts, but since we're using a recipe analogy, let's strain
it a bit more. I like to think of programs as doers, not tellers, so I'll have
them actually employ the recipe, not just provide it.

An object-oriented recipe-maker (that is, a cook) will ask you what you want
to cook. You say cake. It then looks in the pantry and refrigerator, spies
cocoa and flour and eggs, decides a chocolate cake can be made, takes your
ingredients and mixes them together, takes readings of the temperature,
humidity, air pressure, and altitude to create an optimized heating cycle,
plops the batter into the oven, bakes it, and gives you a cake. The next
morning, your wife wants to make some pancakes, so she heats up the griddle,
gets out a mixing bowl, and opens the cupboard to discover that her flour is
half gone. To make her feel better, you give her some cake. She loves it, and
wants the next batch to be made just like it. You admit that you don't
actually know much about how it was made--just that you asked your program for
cake.

A functional recipe-maker asks you what you want to cook. You say cake. It
keeps staring at you. You allow that you actually want chocolate cake, provide
the atmospheric conditions (if you choose to--you can also just tell it that
20 minutes at 350 degrees is fine), and give it some money. It goes to the
store, buys the ingredients, mixes them up, bakes it as instructed, and gives
you a cake. The next morning, your wife wants to make some pancakes, so she
heats up the griddle, gets out a mixing bowl, and opens the cupboard to get
out the flour. Later, she's feeling a bit peckish, so she has some cake. She
loves it, and wants the next batch to be made just like it. You remember what
you told your cook, and know that the cook will always make the _exact_ same
cake if you give it the same stuff (cake type, cooking specifics, money for
ingredients).

Clearly, the functional approach can seem more appealing. But maybe detractors
will say that it can be a bit expensive to keep giving out money for
ingredients like that. However, a good recipe-maker also manages your
ingredients for you. And it doesn't buy flour for pancakes until the moment
your wife opens the cupboard to get some, nor does it buy any other ingredient
until it's absolutely needed--actually being rather thrifty.

Now, as I said, it's a strained analogy. But the one from the article is
really not ideal. I also resent the connotations of equations and recipes--the
casual reader will say, "Wah, math is hard. FP sucks. Gimme my objects--anyone
can cook." And while math certainly plays a prominent role in CS, and CS
certainly plays a prominent role in programming, math is not always required
for normal tasks.

~~~
teaspoon
I'm not sure how you're getting "object-oriented programming" from this
article, except that it was mentioned in passing as an example of a paradigm
that belatedly entered mainstream software engineering. OOP is orthogonal to
the comparison the article is making, which is between _imperative_ and
functional programming.

I found the (imperative : recipe :: functional : equation) analogy to be apt,
especially for the lay audience. I agree that it may not be up to the task of
contextualizing certain language features (like referential transparency; "the
cook will always make the exact same cake if you give it the same stuff"), but
like OOP, many of those features are not inherent to either of imperative or
functional programming, and not important in understanding the difference.

~~~
joelangeway
The article only names the OO and functional paradigms. The reader is led to
believe there are just two.

~~~
teaspoon
"...the split between the recipe-makers (who use a style called imperative
programming) and the equation-crafters (who use functional programming)..."

