Should Students Be Taught With or Without an IDE?
bblazer asks: "Beginning this next school year, there is a strong possibility I will be teaching an intro to Java and an intro to Python course at the local community college. I was wondering what the prevailing wisdom is when it comes to teaching languages - should students be taught with or without an IDE? I am a bit old school and wouldn't mind having them all use vi or emacs, but using a good IDE does have some advantages as well. I should note that the students I will be teaching will have had at least 1 semester of programming in VB or C++." Even though there is limited time in a semester, could a curriculum be constructed to accommodate both methods?
I generally prefer without. My intro CS course (in Java) five years ago was taught using emacs (which I actually didn't like at the time), and part of the beginning of the course was graded on knowing emacs shortcuts. A later course that I was a TA for used BlueJay, and again grading was done dependent on using that IDE.
I am more a fan of letting students choose their own environment. I've been using UltraEdit for a long long time, and I'm very happy with it. My suggestion would be to give students a list of good editor options, but not require them to use any single one. Maybe a later lesson could focus on the debugging potential of one IDE or another (I hate to say it, but Microsoft has some great debuggers). My experience, though, is that the main issue for students is what they're writing, not how they write it.
Bravery is not a function of firepower.
~J.C. Denton (Deus Ex)
debugging through prints.
Now I remember why I hated programming.
I'm going to disagree with the parent and say IDEs. Although I think his point about software development and programming being two separate things has merit.
They should - although you shouldn't assume - have already been taught how to programme. Are they're going to use an IDE when they leave college? You are supposed to be training them for the work place.
First and foremost - teach them good practice, tight simple modules with good comments.
Introduce them to an IDE, show them a couple if you've got time. Assign them tasks using the IDE. Go through the source code line by line. (starting at the end?) Write some really crappy code and get them to fix it using the IDE. Chuck out the IDE and get them to fix more crappy code using whatever masochistic tool you like. Have them debug each others work.
What I'm saying is try to replicate your experiences of the real world as much as possible. Just because IDEs weren't available when a lot of us were being taught doesn't mean we have to perpetuate a crappy situation.
Teach them to be efficient and fast - show them how to use what's available to them so they're not reinventing the wheel.
Ok, now that I've written efficient, we're going to have people argue that IDEs don't produce efficient code. One word... Java?
Ronan