Some years ago, I had the pleasure to program some archaic embedded systems, namely mobile phones, based on a 16bit CPU with a segmented memory model (comparable to the old 8086 memory model). We wrote an application framework (windowing system, scheduler, network stack API and the like) applying a C++ compiler/linker (which had just introduced some brand-new C++ features like templates in its latest version ;-) ). This framework represented the technological base for several customer projects.
Our department was growing, so we employed some recent university graduates. The course curriculum here in Austria allows you to walk through a computer science degree without writing a single line of C or C++ (not to mention assembler).
We didn't really let them touch any core stuff, but still: The new hires started coding as they used to code in their assignment classes under Java: highly inefficient, producing one memory leak after the other, not knowing about the consequences of their code - especially on a system with very limited resources.
Some of them didn't know the implications of a copy constructor invocation (heck, they didn't even know they would invoke a copy constructor on a value assignment - they simply thought they would be working on references as they used to). One time a new hire allocated and free'd memory at such a high rate that we faced serious performance and memory fragmentation problems just because of scrolling through some listbox items (several hundred malloc's and free's during a single keypress).
And just recently I spent half an hour or so explaining our current summer intern the difference between stack and heap. In his Java times at university he never had to worry about that...
For someone who as been programming C++ for several years, it is not too hard to switch to a managed environment that provides garbage collection and the like, as Java or .NET do. OK, some new concepts, but it's a lot of convenience.
What computer science professors tend to forget is that the opposite course is likely to happen as well to those graduates once they enter working life (those who have only applied Java or C#). There is more than Java and C# out there. And this "backward" paradigm shift is a much more difficult one. Appointing inexperienced Java programmers to a C++ or C project is a severe project risk.
