David Gries (in the forward to) Reflections on the Teaching of Programming,2008. Springer.

For 50 years, we have been teaching programming. In that time, we have seen momentous changes. From teaching a first course using an assembly language or Fortran I to using sophisticated functional and 00 programming languages. From computers touched only by professional operators to computers that children play with. From input on paper tape and punch cards, with hour-long waits for output from computer runs, to instant keyboard input and instant compilation and execution. From debugging programs using pages-long octal dumps of memory to sophisticated debugging systems embedded in IDEs. From small, toy assignments to ones that inspire because of the ability to include GUIs and other supporting software. From little knowledge or few theories of the programming process to structured programming, stepwise refinement, formal development methodologies based on theories of correctness, and software engineering principles.

And yet, teaching programming still seems to be a black art. There is no consensus on what the programming process is, much less on how it should be taught. We do not do well on teaching testing and debugging. We have debates not only on whether to teach OO first but on whether it can be taught first. This muddled situation manifests itself in several ways. Retention is often a problem. Our colleagues in other disciplines expect students to be able to program almost anything after a course or two, and many complain that this does not happen. In some sense, we are still floundering, just as we were 50 years ago.

Part of the problem may be that we are not sure what we are teaching. Are we simply providing knowledge, or are we attempting to impart a skill? Many introductory texts are oriented at teaching programs rather than programming— they contain little material on the programming process and on problem solving. And, judging from introductory texts, there is little consensus on how and when to specify program parts, how to document variables, how to teach algorithmic development, etc.

Another part of the problem may be that programming is indeed a difficult mixture of art and science—difficult to do and more difficult to teach. Yet another part of the problem may be that we have not discovered enough about programming and about teaching it. We need more research, experimentation, assessment, discussion, and debate.