Computer scientists are an odd lot. Most scientists are. It hasn't got nearly so much to do with the computers as with the science. Pure researchers, theoreticians, and people in a clean-slate sort of mood tend to prefer a wholly conceptual view of their work to the actual implementation of it.
Engineers, at least the software programmers I know, tend to prefer the implementation, and flick back to theory when they need a particularly rigorous explanation of something.
Computer science more or less grew out of mathematics. Most of the principles governing computers are based in math, all the way from the exponential/logarithmic vagaries that make base-2 so useful, to the complexity theory that governs algorithmic efficiency/efficacy.
So if you were to teach a "purely theoretical" computer programming course, you'd have a lot of paper, some chalkboards, and the code you wrote would tend to have a lot of sub/superscripts and related stuff that doesn't occur in ASCII programming languages. It wouldn't look like the source code most programming students see -- it'd be heavily symbolic. No compilers, linkers or debuggers. No actual computers, either. Recall that for quite a while a "computer" was an unmarried woman with good arithmetic skills wearing a green skirt. They were "deployed" in "clusters" in the basements of military installations. Parallelized, a whole computer-room could calculate a couple of bomb trajectories a day. That's an implementation, not the theory -- but it's useful to recall, because computation is a lot less tied to those plastic boxes of silicon than most people tend to think.
Your typical undergraduate introductory programming course works roughly like this: you take forty people with a broad age dispersion. Of the forty, thirty have used computers (the plastic-and-silicon things) for a while. Twenty five of those can use a word processor. Fifteen of them can use a web browser. Ten of those have discovered online pornography, five use their computers mostly to play games or to silence their kids. A few of these will have taken an HTML class and will raise their hands when the instructor asks "Has anyone here done any programming before?" The ten who haven't used computers have mostly lied about taking the Intro-To-Computers prerequisite. They couldn't get into that course anyway, because it's stuffed completely full of another demographic entirely, the one headed for a lifetime of reading the manual for MS Word all the way through every version.
Each of these introductory programming students has a $49.95 textbook. At the moment it's likely to be on C++. They'll have a lab full of Windoze machines reserved for 2-3 hours a week. The machine will have an IDE on it, likely one or another of Metrowerks' Codewarrior, MS' Visual C++, or Borland C++.
The first program most of these students complete will be "Hello World," and they'll be given about a week to do it. They'll be given structure, sample programs, etc. They'll be told that 'cout << "foo"' is how you print stuff (or writeln, printf, System.println, whatever). It's essentially an exercise in learning the IDE, and inspiring confidence by getting the computer to do something just because they told it to. A few of the hardier ones will try changing the output around.
There's a problem with this. By the end of the course, these students will have a basic notion of loop constructs, conditionals and function calls. They'll also have learned the IDE -- and there begins the trouble. What none of them have yet learned is what the computer actually does when given those loops, conditions or functions. They'll have learned how you tell the computer to do some stuff, but not yet learned the meanings of what they told it. They can read the first few pages of the spellbook, but not yet what any of the magic meant. And when you tell them "Program!" they run over to the plastic-and-silicon computer, fire up their IDE, open a project file, type their name in a comment at the top of main.cpp, and look at you.
An IDE is a contraption for integrating the disparate tools of programming in a convenient way. They try to save time for the programmer, and make it easier to go through the motions. If you were to take one apart, you'd find an editor, build manager, lexer, compiler, assembler, linker, loader, debugger, and probably a bunch of code-analysis components, all talking through the same GUI.
Introductory programming courses don't explain what any of those tools are. A few students will try to bring in code written in MS Word; it won't work, and they'll be told something along the lines of "don't do that, it won't work." When they click the "compile" button in their IDE, it will either work or it won't. If it doesn't, the IDE will tell them what went wrong, and show them what bit of code had the problem. When they've finished, they'll have a bunch more files in the directory than when they started -- they'll be told by the instructor to throw away most of these before they hand it in.
A problem that arises right about this point is that students who get this far are stranded partway between theory and implementation. On the theoretical side, they know what if/for/while/etc mean. On the implementation side, they can write programs that count down from ten and say "blastoff." Below the level provided by their particular programming language is a large blind spot, and most schools don't teach anything more theoretical than that since it involves more math than people looking for vocational-ed can usually endure.
Right about here there's another issue, caused by the IDE. Remember that about three fourths of introductory programming students had prior applications experience. When they learned to write code, they were given another application, one that "you use to write code."
For an experienced, knowledgeable programmer, an IDE is a handy tool that saves some time and provides a few helpful features. For introductory programming class instructors, it enables some small portion of the course to be devoted to the writing of code, lest the whole affair turn into an abstracted version of an MS Word class.
An IDE is a dangerous thing for the novice. In one respect it makes programming more readily accessible. On the other, it makes all the implementation details much less accessible -- either it hides them, or it simply provides no motivation to notice them. "Symbol table" remains an item in a menu that wasn't used during that course they took once. "Compile" is the thing you do that shows you the errors but doesn't run the program. "Run" is the same as "Compile," but afterward your Windoze machine may crash. An if statement is something that does stuff sometimes, but not other times.
The problem manifests itself when students raised from the start on an IDE are faced with a problem with which the IDE won't help. The compilation and linking problem has been sufficiently concealed from casual view that they're unlikely to know where to look, or how to recognize what they see. More than that, they've learned to treat programming problems as if they were application problems -- the business of how to get the IDE to do something for you, rather than understanding how it's actually happening.
Attempts have been made in the past to reduce programming to an applications-level process -- Smalltalk and similar heavily GUI-oriented development environments come to mind. None have proven suitable beyond extremely narrow environments. Teaching a computer to do something is seldom readily convertible to any extant GUI approaches. And instructions given to a computer on an applications level contravene understanding of how things really work, essential to making them work any other way.