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.
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.
But the ingredients can't just mix because those classes don't know about each other! They are good self contained classes. We need to employ the "mix ingredients" pattern. Why is the cake cooker tied up with the representation of atmospheric conditions and why is it determining the policy of the oven class? Is bake a method of the cook or the oven? And woe to the programmer who does not have the patience for the BatterRiseModelFactoryFactory documentation, for she must catch every possible exception to prove the compiler that she is humble, though she is forbidden from continuing executing in such an event, for only with a stack can execution proceed and only by unwinding a stack can an exception be caught!
Thank you for giving me something rant about. I like your take on the analogy quite a bit, though I think your take on OO casts it in too good a like by instead describing simple structured 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.