1
$\begingroup$

I am growing suspects that the ubiquitous analogy between algorithms and recipes be not so well founded, especially for theoretically oriented students. I am wondering if this may contribute to the evidence of students having difficulties with even simple loops. I believe that bad analogies make more harm than no analogies, so I ask.

My wondering is that recipes, if superficially similar to the idea of sequential steps, do not really encode the logic that is sought to be explained: the logic of state transitions. Of course there are state transitions in recipes, but i do not feel they being the characterising properties, nor are they the target of attention (I also like cooking). State transitions in recipes (and similar physical operations analogies) seem to be not even caused by the "program" but just happening because of physics. And typically what we get from students struggles is exactly their inability to follow (or design) state transitions. Probably because a fundamental property of a real computer program is that of being the acting cause and not the observer of state transitions, and this is not captured by the analogy. Another issue is that computing systems are typically discrete while physical analogies tend to be continuous, both in time and measured (variables) dimensions.

What screams for attention in recipes are instead "data" dependency constraints (cannot throw in the spaghetti before the water boils), or a kind of "event-driven" situation, and i do not recall seeing students struggling with data dependencies, which might be because 1. the recipe analogy is good in teaching them or (I suspect more probably) 2. it's not what they need help for: data dependencies being more innate than state transitions, especially in a forcefully sequential environment (of course this is a hypothesis, any experiments known?).

On a more concrete side it seems to me that the real world software counterpart of recipes are those things that we usually call scripts: something I love and had made a lot of and which I know perfectly fit their niche problems, but not something that is known for exposing nice theoretical properties, which, I suspect, is what matters more when learning, in order to build a clear mental model of algorithms (and because my pupils are generic science students and not specialist computer developers).

Realistic programs, and especially subprograms if we want to divide et impera, are not sequences of operations but sequences of state transitions.

What do you think of this analysis? Have any empirical data? Does an analogy that takes more care of state transitions exist and I have missed it?

$\endgroup$
  • $\begingroup$ Re, "Is the ... analogy ... good or bad?" Good or bad for what purpose? IMO if your purpose is to explain what the word "algorithm" means, then "recipe" comes pretty close: If you follow these steps, ..., you end up with a loaf of bread. If you follow these steps, ..., you end up with the greatest common divisor of two given numbers. But if you aren't trying to teach what "algorithm" means, then what are you trying to teach? $\endgroup$ – Solomon Slow Feb 28 at 3:09
  • $\begingroup$ Re, "Realistic programs are not ..., but ..." If you are trying to teach somebody how to design computer software, then that's a whole other topic. You are absolutely right: A software system is not an algorithm and an algorithm is not a software system, and it really doesn't matter whether or not either one of them bears any resemblance to a recipe. $\endgroup$ – Solomon Slow Feb 28 at 3:14
  • 2
    $\begingroup$ Re, "...scripts..." A script is a computer program. Period. The only reason we call it a "script," is either that we are trying not to scare off somebody who thinks that programming is too hard to attempt, or else we want to belittle the efforts of somebody who we think has not earned the title, "programmer." $\endgroup$ – Solomon Slow Feb 28 at 3:18
  • 1
    $\begingroup$ We use the term scripts to differentiate between short functions built at runtime by a user from the core application code $\endgroup$ – pojo-guy Mar 1 at 0:37
5
$\begingroup$

Actually, you are loading a metaphor/analogy with too much import and influence. An analogy isn't supposed to be exactly the same thing as the thing of which it is an analogy. It is only supposed to be similar to that thing in some way. But not in all ways.

Analogies and metaphors in teaching computing are intended only to overcome the initial static inertia caused when a student has no idea whatever about a concept. To use it well, you need to do a couple of things, one of which is to move away from it as soon as is possible. But the more important thing is to be aware of how the analogy fails to be the thing analogized and to watch for misconceptions in the student's mind that are actually induced by the analogy itself. You then need to give a correcting lesson.

I can analogize loops with cooking recipes as: stir the sauce until it thickens. This isn't an algorithm, of course, since it has undefined terms, especially in the stopping condition. If that gives the students a quick mental picture of repetition then fine. But if they put too much weight on "stir" or think that an imprecise stopping condition is normal in programming, then I need to make a correction.

Sometimes that correction is with another, better analogy, but usually it is just a more precise and technical discussion.

Don't put so much weight on any given metaphor. Use it to introduce concepts but know when it fails and make corrections for those (hopefully few) students who draw the wrong conclusion. You can thus avoid being overly detailed and pedantic, losing students in the interactions between all of the small bits that go into anything complex.


I've been told that professional bakers follow their recipes more faithfully than professional chefs do. More careful measuring, for example. But even bakers have to deviate as the flour they use can vary in moisture content, requiring adjustments.

$\endgroup$
  • $\begingroup$ Thanks for the good answer, however I tend to disagree, on the dismissing of the point. As for the introductory purpose, that's true for metaphors, but it's really needed only if the new concept has some complexity, elementary or simple concepts should be well understandable on their own. As for analogies they ought to be ana-logic, carrying the same logic, to help reasoning. If the terms do not share the fundamental logic points and are just to be forgotten early then they do harm and not good. More so for young learners possibly untrained to know that analogies fail. $\endgroup$ – user9137 Feb 27 at 21:52
  • 2
    $\begingroup$ They have to share some but not all points of logic to be useful. And it is your job to teach them the limitations - especially for young learners with less experience. $\endgroup$ – Buffy Feb 27 at 21:54
  • $\begingroup$ Yes, but the points actually shared should be the fundamental ones, and my doubt is about this. I cannot see how "stir until thickened" shares a fundamental point with while(i<n), I mean: not before understanding state transitions. The point shared (sooner or later we will stop, and the computing one doesn't even guarantee that) is arguably the only one that doesn't need explanation. $\endgroup$ – user9137 Feb 27 at 22:13
  • 1
    $\begingroup$ Actually my example is more like repeat x until y. But you can also say while the sauce is thin, stir it. Match the analogy/metaphor to your lesson, of course. And sometimes the sauce never does thicken. It is fairly rich (both the analogy and the sauce). But don't overload it. $\endgroup$ – Buffy Feb 27 at 22:22
  • $\begingroup$ Well I don't really think of a difference between while and until, but I digress. The point is not so much my lessons, for of course I can say what I feel and test the pupils; it's not me the one who I worry may overload the meanings: it's the students and their free access to resources that may use this kind of analogies having me then do more work to unteach them something wrong. $\endgroup$ – user9137 Feb 27 at 22:37
5
$\begingroup$

I have never been a professional educator for computer programming at the very beginner level, but I have used the "recipe" analogy in a lot of situations where I am not acting as a formal educator.

However, I flavor (see what I did there) the analogy, by describing the computer as the absolutely most simple-minded assistant cook that you can possibly imagine. So if you want a cup of sliced carrots, you have to tell them how to slice a carrot, how to know when they have sliced enough, and tell them to keep slicing carrots till they have enough.

$\endgroup$
1
$\begingroup$

I think the analogy holds up rather well.

Firstly, a program is a text and so is a recipe: they are both texts.  A text can be read, shared, and edited.  The recipe is typically meant to be followed & executed by a human whereas the program is meant to be followed & executed by computer language.  Both are meant to be read and updated, refined, adjusted, maintained by humans.

Further, a text can be analyzed, for, as you point out, state transitions, and perhaps steps or operations that accomplish those transitions.  The recipe starts with raw ingredients and forms them into finished product, whereas the program consumes input and turns that into desired output.  Both share the concept of intermediate results that are in turn used to produce the results for the next step and finally the finished product.

For another, a text can be analyzed for logical errors, which applies to both recipes and programs: a recipe might have typos; a recipe may suggest doing something in an order that is physically impossible — computer programming has these errors as well.  If you post your recipe online you might get feedback on how well it works and what can be adjusted.  A code review is similar, though in programming we also have the automated feedback from the compiler or interpreter.

Recipes and programs can both be tested.  The both allow some variation of inputs and outputs, as well as introducing a notion of acceptable inputs and acceptable outputs.  Sometimes these things go unstated, other times, formally stated (a souffle should stand and not fall, a program should produce certain results).

As @Buffy is saying you can take the analogy further in that recipes can have conditional steps as well as repetitive sections.  Recipes can even have formulas (e.g. for every 1000 feet in altitude, boil another 3 min).

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.