I definitely agree with the authors' view that many students simply "twiddle with language constructs." Sometimes on hours, it will seem to me as if all students have done since their last vist to the TA room is move around a few semicolons. Perhaps if mhc included in his useful tool a list of "attacks" to common CS problems (i.e. if you know how many times you want to do something, or you can determine it from some data, use a for loop. If you want to do something while a condition is met, use a while loop, etc.)

However, I feel that in some cases, the authors used overly complex language to describe solutions to relatively simple problems. If a student doesn't understand a concept, using a lot of ornamented dialogue isn't really going to help their level of comp rehension. If I got a handout full of abuttings, subgoals, formalizable intermediate languages, and interleaved compositions, chances are I wouldn't look at it more than once. Things with titles like "Shoeburger" would be more likely to catch my eye.

The underlying point of the article is a valid one, however. There are definitely more than just the aspects of syntax and conceptualization in CS. Students often get lost in the translation between the two; a programming language is just that: a langua ge. It has subtleties that need to be learned, and perhaps, unlike a spoken language, total immersion with only a basic understanding of the "rules" isn't the way to go.

I'm on it baby!

[Note to self: you are on a questioning everything...] What do you think is the best way to teach people how to go from syntax to conceptualization or vice versa? [Depending on background, different people have different problems.]

I strongly agree with Lucas that overly complex analogies, big words, and "clever" explanations can just as easily confuse students. Explanations should be kept simple, and analogies should only be used when appropriate.