A good analogy I've heard to explain this is how you'd request a glass of water from the kitchen from a friend versus a computer. You can simply tell your friend "get me a glass of water" and they'll understand what you're asking. With a computer though, you must be completely explicit with your instructions, for example: walk to the kitchen, open the top left cabinet, take out a glass, put it underneath the faucet, turn the faucet on until the glass is 80% full... etc.
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.
Oddly enough, you could repeat this exercise today, strictly with the computer itself. How would you request from a friend a list of the files in a particular folder whose names end with a particular extension? If it's a GUI based system, you have to be just as explicit as with the glass of water. In fact, written instructions for performing computer operations are often page after page of pictures of dialogs with circles and arrows, plus paragraphs of text. And your dialogs don't look the same because you have a newer version of the OS.
And people get them wrong.
This didn't really strike me until I started using Linux, even though I had originally learned on command line based computers. The same instructions for Linux users are a few lines that you enter into a terminal. I've even noticed a trend towards documenting Windows operations via a series of commands entered into the DOS box.
While that is generally true, one should remember that programmers spend a lot of their time trying to help abstract that all away. I wouldn't ask my OS to open the top left cabinet and take out a glass, I would ask it to give me a glass. The OS was built by people who already know the optimal glass fetching method, so I just need to tell it what I want, not how.
The problem there is that if you want to get anything original done, you're gonna need to start getting to that low level where the abstraction isn't there. We sort of side-step this in education by starting with heavily abstracted systems like greenfoot, where you ONLY say what you 'want to happen', like 'object should move left'. Once students raised on those systems start to encounter real problems, they falter, because they've never had to cope with the computers stupidity before.
