For50years, wehavebeenteachingprogramming.Inthattime, wehaveseen- mentouschanges.Fromteachinga'rstcourseusinganassemblylanguageorF- tran I to using sophisticated functional and OO programming languages. From computerstouchedonlybyprofessionaloperatorstocomputersthatchildrenplay with. From input on paper tape and punch cards, with hour-long waits for o- put from computer runs, to instant keyboard input and instant compilation and execution.Fromdebuggingprogramsusingpages-longoctaldumpsofmemoryto sophisticateddebuggingsystemsembeddedinIDEs.Fromsmall, toyassignments 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 re'nement, formal development methodo- gies 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 notonlyonwhether toteachOO'rstbutonwhether it can be taught'rst.This muddled situation manifests itself in several ways. Retention is often a problem. Our colleaguesin other disciplines expect students to be able to programalmost anything after a course or two, and many complain that this does not happen. In some sense, we are still ?oundering, 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 introductorytextsareorientedatteachingprograms ratherthanprogramming- theycontainlittle materialonthe programmingprocessandonproblemsolving.