Comment Java really isn't the problem, in my experience (Score 1) 1267
I fairly recently graduated from a Computer Science program -- it was, frankly, a total disaster, and rather then getting lots of interesting and detailed technical tidbits, I wound up re-hashing things I'd taught myself years before.
But to speak more to the point of this story: my college had just switched to Java (from C++) as it's primary teaching language, but the language was definitely not the issue, it was the approach. The first semester programming course progresses more or less as follows:
- A brief lecture on a topic is presented and a demo program is shown
- Students move into the lab
- Step by step, students *COPY AND PASTE* code to re-create the demo program
- (On the "good" days:) students are asked to make small modifications to the code to effect minimal changes
- Occasionally, these minor changes are slightly more complex, in which case they constitute a "project"
- Later: everyone passes with a B or better
Most of the students have no idea whatsoever how to actually write a program from scratch by the end of this semester (small wonder, since they never had to do much more than hit ^C ^V). To compound this mess (and officially to avoid boring the students) the college provides a (rather poorly constructed) library of graphical components which the students get to use so they can "jump right in" to "doing graphics". Unfortunately the library obscures virtually all of the details of how any of the graphical components work, and once the students become used to it, it's very difficult (or impossible) to get them to shift to using something more direct (drawing via Graphics objects or using AWT, for example).
A further consequence of this approach is that, since time is spent learning the graphical library upfront, key concepts of "real" programming are deferred, sometimes until very late in the semester. This means they're being taught under serious time pressure to fatigued students who have already learned an "easy way" to "program".
For some reason, Java seems to somehow be connected with this idea of "instant gratification" programming, but it's certainly not Java's fault that this is how material is presented to students. You certainly could teach this way in C or C++ for example (although it might take a bit more work upfront to build the "instant gratification graphics library"). It's unclear to me if the problem is lazy or confused instructors, a haphazard and indifferent educational system, or if it's some need to ensure that no student is ever the least bit bored or challenged by any material, ever.
But to speak more to the point of this story: my college had just switched to Java (from C++) as it's primary teaching language, but the language was definitely not the issue, it was the approach. The first semester programming course progresses more or less as follows:
- A brief lecture on a topic is presented and a demo program is shown
- Students move into the lab
- Step by step, students *COPY AND PASTE* code to re-create the demo program
- (On the "good" days:) students are asked to make small modifications to the code to effect minimal changes
- Occasionally, these minor changes are slightly more complex, in which case they constitute a "project"
- Later: everyone passes with a B or better
Most of the students have no idea whatsoever how to actually write a program from scratch by the end of this semester (small wonder, since they never had to do much more than hit ^C ^V). To compound this mess (and officially to avoid boring the students) the college provides a (rather poorly constructed) library of graphical components which the students get to use so they can "jump right in" to "doing graphics". Unfortunately the library obscures virtually all of the details of how any of the graphical components work, and once the students become used to it, it's very difficult (or impossible) to get them to shift to using something more direct (drawing via Graphics objects or using AWT, for example).
A further consequence of this approach is that, since time is spent learning the graphical library upfront, key concepts of "real" programming are deferred, sometimes until very late in the semester. This means they're being taught under serious time pressure to fatigued students who have already learned an "easy way" to "program".
For some reason, Java seems to somehow be connected with this idea of "instant gratification" programming, but it's certainly not Java's fault that this is how material is presented to students. You certainly could teach this way in C or C++ for example (although it might take a bit more work upfront to build the "instant gratification graphics library"). It's unclear to me if the problem is lazy or confused instructors, a haphazard and indifferent educational system, or if it's some need to ensure that no student is ever the least bit bored or challenged by any material, ever.
