Being an active contributor to technical forums I am often faced with surprisingly simple questions about basic programming environments from computer science students. Students are often lazy and why should it surprise me that so many don't bother to learn the basics, right? Maybe, but too often it is ones who are otherwise bright and not at all lazy. So what is the true problem?
Thinking back to my own basic programming classes I think I can see the problem clearly. I cannot think of one professor that explained the programming environment in class. The books tend to skip over those parts as well.
What is the number one problem students have with their Java projects?
Classpath.
Something as simple and basic as that, it's just not explained in class. Is it too simple and ought to be self-explanatory? Perhaps, but I wouldn't expect a first year CS major to grasp the concept of classpaths without at least a basic introduction, why are CS professors expecting it? Sit a student in front of a tool like eclipse and I guarantee their eyes will glaze over and a simple concept like a compiler will not occur to them on their own.. command line? Forget it.
With the development environments getting more and more complex each year and the command line being something of the past (unless you're a unix geek like me) I think CS programs should look into providing classes in basics of development environments. Using tools like source control, IDEs, etc. It would help the students understand programming better and give them a better start in the workplace.
TrackBack URL for this entry: http://www.unix-girl.com/mt/mt-tb.cgi/1402
I agree that the basics often are glazed over; I noticed the same thing happening in my computer science class. I believe that classes should dedicate time to learning different development environments.
In my Java class, for example, after I introduced people to JBuilder, the command-line, BBEdit, BlueJ, etc., many people switched to using one of those instead of what the class taught exclusively: CodeWarrior. If a little time is spent in each environment, then it gives the teacher a chance to explain some of the technical details (which are necessary for some methods, such as the command-line) and it won't seem like unrelated detail (safe to ignore) to the students.
#Ironically, I stepped in during a masters Java class for exactly this reason: we were using nothing but the awk and vanilla Java, so an introduction was required... it was just never planned.
Also, for HTML classes I've taught, I start with notepad; for MFC/C++ classes, I required a look into the raw Win32 API, for the same reason... as good as modern IDE's are, I believe some background is required - how else can ya survive if the IDE goes belly up on you? (as Forte often did for me!)
#On a related subject, I find that younger (than me) software people tend to not understand some of the fundamentals of software particularly in terms of addressing. If the first programming language that you learn is assembly language on a small system you tend to learn the following:
* what addressing (read pointers) really means
* memory is not infinite
* how to debug at a low-level
* get a better general understanding of how computers work
The drawback of modern development environments are that people only learn how to point/click without knowing what is really happening.
I'm personally a big fan of the idea of introducing tools like bug tracking and (especially) version control systems as early as possible in a CS program. We had a lot of trouble with cheating back in college, and people spent a lot of time and effort writing programs to detect it, but what if you just required the revision history for the project to be passed in as part of the final submission? It'd be trivial to check to see if the students had just pulled a completed project out of nowhere on the last day before the due date.
#There's some thought that this is computer "engineering" and not computer science... there's also some benefit to treating "wielding an editor/debugger/command line" as a distinct (and seperately taught) skill from programming or designing software...
#Yes, I may agree with some of that, but the problem I see often is students unable to solve a simple compilation problem due to things like an unset CLASSPATH because they are simply unaware of it!
#Knowing how to drive some tool relates to 'computer science' in the same way as knowing how to sharpen a pencil does to pure mathematics.
i.e., I suppose it's pretty essential, but it's not the core of the subject.
I guess the first course of the first term should offer basic familiarity with the tools. Someone probably told us how to switch on an ASR-33, but most of that sort of stuff was picked up in lab sessions (from long-suffering grad students) rather than in comp. sci. lectures.