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?

Comments

Without

[Hegh]

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.

Re:I would say IDEs

[rossifer]

no.

as long as they trust the editor to catch their mistakes, they'll never actually learn to avoid them; they'll simply let the IDE be their guide and never learn it.

Exactly. I've been developing software for 12 years and I still go back to emacs whenever I want to learn a new technique, technology, or toolkit. The dev work may take a little bit longer, but I learn so much more when I have to search through directories or look up an interface in the documentation that you just don't get with an IDE.

I strongly recommend staying close to the metal as possible when learning, then gradually getting more abstracted as your grasp of the underlying skill develops.

(The AC is probably one of that group of programmers whose code I have to rewrite, but I guess we'll never know for certain... :-)

Regards,
Ross

Re:I would say IDEs

[Anonymous Coward]

Exactly. I've been developing software for 12 years and I still go back to emacs whenever I want to learn a new technique, technology, or toolkit. The dev work may take a little bit longer, but I learn so much more when I have to search through directories or look up an interface in the documentation that you just don't get with an IDE.

Whenever I'm trying to learn something new I get out the hard drive and move the bits around myself. IDEs like emacs just get in the way.

Re:I would say IDEs

[ronanm]

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

Re:A scary story related to this question

[DrNoNo]

After digging further it dawned on me that the root of the problem was that these students had never even heard of a linker, had only the vaguest idea what a compiler was, and weren't sure how the editor was different from the compiler. They were quite certain that single-stepping through code made use of the compiler, though.

Yes, all too familiar. When I teach C, lesson 1 is Preprocess, Compile, Assemble, Link. Then we do 'Hello World' with notepad, compiling by stages from the CLI, looking at all of the intermediate files. Only after that do we talk about C programming.

The benefit is that from the outset, everyone understands the process, and from the outset, if something doesn't work, you can talk about did the compiler fail or the linker - which you have no meaningful basis to do without explaining the process.

The problem wth doing 'Hello World' first is that learning a programming language is like climbing glass mountain. There is so much to learn before you can do anything useful, so conventionally, teachers are very tempted to miss things out. The thing you can afford to miss out is the IDE, going through the Preprocess Compile Assemble and Link process is far more essential. By setting that scene, your students have a context against which to understand everything else.

Trust me it works. With groups of 3 on a 3 day course, after 1.5 days we do a Yourdon analysis of the mastermind game [see this if you don't know what it is - we don't do graphics, we do it with numbers on the CLI], then we split it into 3 modules and each student codes a module. Then they share their object modules NOT the C code, they link them and we always get a working program either first time or after 20 mins.