Bring in a few loaves of bread, jars of peanut butter, and jars of jelly, with a few utensils. Also, lots of paper napkins.
Have the students spend 10-15 minutes writing a 'how to make PB&J sandwiches'. Select volunteers to read their instructions while you follow them as a computer would. Explain that this is how computers work.
Get some bread: grabs entire loaf of bread, uses the entire loaf for following instructions.
Open the loaf of bread: Rips open the entire package.
Open the jar of peanut butter: Fails to rip the lid off.
Spread peanut butter onto bread: Grab a big handful of peanut butter and spread it messily over the bread.
You can demonstrate how a more flexible language allows you to not just stop and crash (ie. Unknown command 'open peanut butter') but can result in far worse results.
You can even get into the different levels of languages by showing the difference between a motion by motion (assembly) instructions vs. one which assumes general sandwhich knowledge (C/C++/etc).
I saw this exact demonstration (PB&J) in I think 5th or 6th grade. Which would have been 1995/1996. This was before I had any interest in software. But I do remember that, in fact I was thinking about it when reading earlier comments in this thread! So maybe it stuck with me and helped in some way.
One problem is that programmers accept this stupidity from the machine rather than try to fix it. For example, if the computer had a definition of a good PBJ and some sort of solver, it might just figure out how to construct a PBJ with the given materials. Or maybe it would ask for clarification of some steps. Of course we don't want to treat all problems as general cases to be solved on the fly, but I don't think we should accept complete stupidity from the machine either.
Programmers don't accept it, which is why higher level languages exist. At some point it reaches 'good enough' and most of us settle with some language, but there are always others pushing out new languages to fix some shortcoming they see.
It would be great to add to this to break each 'module' down to a separate student, and then try and use them in sequence to complete the task, with a master sheet telling you when to use each module.
I do this. I just don't give them props. And it is a great effective approach that also gets them thinking about basic algorithms by breaking down problems.
Bring in a few loaves of bread, jars of peanut butter, and jars of jelly, with a few utensils. Also, lots of paper napkins.
Have the students spend 10-15 minutes writing a 'how to make PB&J sandwiches'. Select volunteers to read their instructions while you follow them as a computer would. Explain that this is how computers work.
Get some bread: grabs entire loaf of bread, uses the entire loaf for following instructions.
Open the loaf of bread: Rips open the entire package.
Open the jar of peanut butter: Fails to rip the lid off.
Spread peanut butter onto bread: Grab a big handful of peanut butter and spread it messily over the bread.
You can demonstrate how a more flexible language allows you to not just stop and crash (ie. Unknown command 'open peanut butter') but can result in far worse results.
You can even get into the different levels of languages by showing the difference between a motion by motion (assembly) instructions vs. one which assumes general sandwhich knowledge (C/C++/etc).