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

Not at first

[trewornan]

I'd have to go with a non-IDE approach initially and introduce an IDE later on so as to avoid teaching dependence on something which shouldn't be required. Incidentally - vi would be a bad idea, it's got to much of a learning curve when they're really supposed to be learning programming - gedit or notepad might be better.

Re:Not at first

[kunakida]

I agree about not starting with an IDE.

IDE's are a crutch, and the make/build files they create are not amenable to automation.

If you are teaching on Windows, Notepad is OK, but Notepad++ is a good open source editor with color syntax highlighting for various languages.

Unfortunately on Linux, the Editor should be vi (maybe not as a first editor). It is available on almost any Unix like platform (even Windows)

I would also suggest not letting them use a debugger at first.

Use printf, System.out.prinln, Logging, Trace macro, whatever.. It improves the ability to deal with finding and fixing bugs, as well as promoting a personal coding style that avoids bugs. Test early, test often. Code a little, test a litle. Write literate code, etc.

Using a debugger all the time is a crutch that makes it too easy to not bother with working on your code quality. And when they get to systems that don't have a debugger, they are clueless.

Re:Not at first

[Anonymous Coward]

Good advice. I'd suggest the command-line approach not just because it takes away their dependence on a particular IDE, but because it gives them a better understanding of traditional/basic program design, ie the engine, powertrain, and suspension instead of the chrome door handles. Better to hit them with cryptic command line options and the need for a sharp eye/correctness in freshman year than to hit them with it junior year. It may turn some of them off at first, but if they're majoring in this, it's likely going to be a career for them, not a sideline. Anyone's particular like/dislike for Unix should not an issue, since Microsoft gives away a suite of compilers and API's free as well, not to mention Borland compilers and all the other open-source offerings that have practically been ported to toasters.

... Yes and no

[GWBasic]

No, students should not: Not using the IDE shows students everything that goes on "under the hood" during compilation.

Yes, students should: Part of teaching programming is showing students how to best use all tools at their disposal. IDEs have some valuable features that are vital to professional programmers.

IMO, the best time to go without the IDE is around the same time that you teach assembly. The non-IDE experience is mainly valuable to students who are going to be professional programmers. For into-type classes where there will most likely be non-major students, keeping them in the IDE will help them be more effective if/when they ever need to program in the future. Likewise, once you reach very advanced CS classes, your students will have better things to worry about then command-line switches, and thus will be able to make good use of the IDE's features.

Again, the above statements are just my opinion.

depends on what you want to teach

[yagu]

It depends on what your goal is for teaching, but by your words, "I will be teaching an intro to Java and an intro to Python course", using an IDE will mask much of what could be valuable in learning, to the extent students don't even "get" some of the important underlying principles.

I've seen kids of friends who ostensibly have taken "programming" classes, and virtually all of them are IDE based curricula. And every one of these kids lacked the most basic understanding of programming. They could cobble together a simple form, but lacked skills to extend much beyond.

Sometimes it's the school/teacher's fault. I know of one example where a teacher had to teach java, and had never used java before. The kid I know who took the class constantly complained about how stupid the teacher was (he mentioned she had a "Java for Dummies" book for herself). She not only didn't know and understand java, but picked an inferior IDE (I won't start any flame wars by naming it, but it was lesser known, and lacking in features).

Admittedly I'm from old school, I started with a 3Gl (PL/I) as an introduction, and my second course was assembly. Things are obviously different today, but I'm glad I understand technology at the level I was required to learn it. I don't think I'd have insights for solutions today without that background.

Since you're asking for opinions: If you want students who'll come back later and thank you, try to emphasize the language and its semantics in your curriculum, and sprinkle in a little exposure to IDE late in the course (that indeed will server a useful purpose).

Good luck.

YMMV.

Re:depends on what you want to teach

[xero314]

You can fail to teach/learn the basics of programing with or without and IDE. I don't think the fact that an IDE was used in a class is the cause for not knowing the programing basics. I assume the original poster was not talking about using a drag an drop IDE like Visual Studio for VB, but something more on the lines of JCreator, JEdit or Eclipse (sorry for the Java centricity). Knowing the basics of programing is very important yet most developers under the age of 30 have no clue what those are. But since the original poster was talking about teaching a java class the students should probably have already taking a programing basics/fundimentals class.

Re:depends on what you want to teach

[Sax Maniac]

There's a big difference in IDEs. I've taught and intro to Java class that had no programming prerequistes, and so was not intended for CS majors. I had a choice - there were people who could barely use computers at all. What was I going to do, point them at the JDK, and expect them to learn how to use a command-line compiler and Notepad? We'd spent a month getting "Hello World" compile, and they'd wind up knowing nothing more about Java or programming at the end of it. Learning how a command-line works is not the same as learning how a programming language works.

So, I pointed them to a super-minimal shareware IDE. It had little more than an integrated editor and button that you can run the program, but that was enough. No form or GUI designers, so they can concern themselves with thinking algorithmically, and not what font to use on which button. The only stuff the IDE hid was the mechanics of compilation, the fileystem, and running.

Still, the IDE is not the point of the class. I'd never test them on keyboard shortcuts or anything similarly stupid. Anyone who wanted to buy a different IDE or go with notepad was perfectly free to do so.

It worked, some of the students really went from knowing nothing about computers at all, to actually writing working programs.

Focus on the goal of the course

[Subacultcha]

There's good reason for any developer to be familiar with a good IDE and with tools like vi and Emacs, but do you really want to spend valuable classroom time teaching them about editing tools instead of the language?

You probably should spend some time during one class to discuss the choices available and what your own preferences and biases are, but they'll probably have to use whatever their employer uses when they get into the workplace. Better to spend your time teaching them to be carefull and thoughtfull coders and they'll use that skill to decide what environment to code in themselves.

Emacs and Ant

[jonabbey]

I'd recommend emacs. You'd be giving them a tool powerful enough to let them get work done, but not yet a tool that would remove the burden of thinking from them. They'd have to spend time learning a couple of handfuls of command key sequences, but all in the service of competently manipulating the source text, not in the service of learning how a given IDE wants to frame the software development process for them. If you wanted to help them put their code together, you could give out handouts for Jakarta Ant.. that way they'd get to directly touch and view the construction process for their programs.

Emacs and Ant are also available on all platforms your students might conceivably be using, whether it be Windows, Mac, or Linux.

Re:I say no IDE

[coshx]

Going by this logic, should we not let them use a shell, but rather force them to launch the compiler through execve calls (how one would write the launcher program itself and run it is beyond the scope of this comment).

Or should they start off coding in assembly or even machine code?

At some point, it makes sense to abstract away details so that students can understand important concepts. Now, if your assignments or understanding of the concepts you were taught required knowledge of javadoc or jar, then I agree that your teacher did not use the right tool(s) to teach these concepts, or should have modified the course so that these tools weren't needed (e.g. generate documentation in eclipse should have been all that they needed to run).

So, given this, do you still believe that an IDE abstracts away too much of the detail needed to understand OO, Algorithms, and Data Structures? If so, which needed details are left out?

Re:Go with what they are familiar with.

[jma05]

Our university introduced students who are otherwise not programmers and will not be programmers - Java with Vi (or Pico - most students preferred that due to the learning curve). After the black unix terminal screen, now the students think programming is a black art. Those that started programming with Access and VB atleast are not afraid of programming and can create some simple data tools for their work (They however over estimate their skill but I prefer this outcome for our specific course). Since, real learning happens outside class, I think it is very important to make the students get interested in programming and let them have little rewards (It's a lot more fulfilling for students to get a GUI app that manages a database than see number crunching at the terminal).

I think the environment should not interfere with the actual subject content since the instructor will often leave the students alone in this area. I thoughts are to first determine what you want to teach - and choose the easiest tools for the students.

Teaching how to use an IDE is a waste

[Error27]

Don't teach vi. That's a waste of time if the class is about programming. Let the students use whatever they want and figure that out on their own.

Visual C++ really sucks. You've got all these weird autogenerated project files. With C++ it's simpler to just not use an IDE at first. Python IDEs are much easier since python programs don't need a build system or any of that.

Teach whatever will let you focus most on Python or Java and the IDE.

This is unfortunate

[John Nowak]

In an intro to programming class, you should be teaching true programming concepts... Not Python or Java or anything else. Teaching from a book like How to Design Programs using Scheme is the way to go in my opinion. Give them the concepts, not knowledge of Java or an IDE that will be obsolete in five years. If they know how to truly *program*, they can handle the IDE themselves later.

Re:I would say IDEs

[krunk4ever]

not saying what you said isn't insightful, but what you said is like saying people should type essays without a spell checker. honestly, you won't be able to use an IDE if you didn't know how to program. IDEs make it simpler by catching simple and common mistakes like forgetting to close your braces or missing an ending parenthesis. forgot which method it was called, no need to open the source code again, just have it display all the method names of the given class. it's not like the IDE will magically write code for you if you didn't know what you wanted.

using an IDE has nothing to do with learning debugging in my opinion. most IDEs themselves already contain great debugging tools, unless you're thinking about the non-GUI ones. at that point, it's just preference, both debuggers are just as powerful, one having advantages that the other doesn't, but also has disadvantages the other doesn't.

I agree when you first learn, notepad would be useful to teach skills, but by the time you get to even like emacs or vi, they already come with a bunch of tools like auto-ident and coloring (which is another thing that IDE supports). IDE makes life easier, and that's that. Just like a spell checker or autoformatting document. even with a spell checker and grammer checker, one still needs to double check for mistakes that the tools don't see. if you think a spell checker finds every problem, you're wrong. Just like those who have the same mentality of an IDE.

A scary story related to this question

[swillden]

Several years ago (early 90s), I was hired as an adjunct faculty member to teach some night classes at my local university. The first class I taught was "Advanced C++", which was a fourth-year CS class, and presumed that the student had previously taken "C++", and before that had taken a variety of other programming and theory classes, working in Pascal, assembler and C, at the least.

During the first week of class, I gave them a quick review of C++ syntax. One evening I touched briefly on the 'static' keyword and gave a quick rundown of its meanings in various contexts. When I mentioned what it does in a global scope (make the symbol local to the current compilation unit), I could see glazed eyes and baffled expressions so I started asking some questions.

Well, they didn't know what a compilation unit was, so I explained that, but they were still confused. 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.

These were Computer Science seniors, most of them one semester away from a Bachelor's Degree. I was shocked and dismayed to think they they could have gotten that far without ever understanding these pretty basic concepts. I'm still confused as to how they could have passed their compiler design course without figuring out what a compiler is.

The reason the students all lacked this basic understanding was, of course, the fact that they had used nothing but IDEs (specifically Turbo Pascal and Borland C++), except in their assembler class, and that had been done entirely on paper, so they never actually had to use an editor or an assembler.

I didn't have time to teach them these things, of course; I'd also discovered that most of these students had also managed to pass their previous C++ course without learning hardly anything at all about C++, so we had a great deal of material to cover. My solution was very simple, and probably somewhat cruel: I announced that I would compile and run all of their programming assignments on a Sparcstation, using the GNU compiler. I required all assignments to be e-mailed to me in a .tar.gz file that included source, makefile and any necessary supporting files. I informed the students that they were welcome to do their development on any platform they wanted (everyone had PCs and Borland C++, of course), but that any assignment that failed to build and run on the Sun would get a maximum of 50% credit, and probably far less, so testing on the Sparcstation was highly recommended. There were plenty of X-Window terminals in the lab, so there was no problem getting access to the equipment.

Nearly a quarter of the class dropped that week. The rest learned something, though, so I don't think that was such a bad outcome.

Re:A scary story related to this question

[Anonymous Coward]

I agree completely with your approach.

In my CS programme they taught us a bit of Pascal and Modula three in the beginning (first and half of second year) of the programme -- always in the context of the relevant concepts involved. From that point forward there was hardly any teaching of a 'language', as, for example, our concurrency course did an optional one-week intro to C++ and then focused on a myriad of concurrency issues, paradigms, etc.

All of our assignments required the submission of working code as well as our various documented (and working and demonstrable) test cases.

Honestly, it wasn't that difficult. And the question of what editor we used, IDE, etc. was completely out of the scope of the class. Honestly, there'd have been an uprising if they had tried to dictate the tools we used to write the solution. By the third year, there were various grumbles on why we had to even use a particular language for our algorithms course. (in fact, there was a short-list where merely for the professor's sanity.)

I think any university or even community college level course that intends to teach a particular toolset for the purposes of the course has the wrong approach. Perhaps familiarization with a tool to help jump-start the process -- but in the real world people use a wide variety of things. (whether it's vi, emacs, pico, some fancy IDE [maybe emacs!], or anything else.)

Similarly in many of our group (and non-group) course assignments we started using CVS/RCS not because it was mandated but because we were all becoming seasoned professionals.

Just my two or three cents!

Mark

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.

Re:A scary story related to this question

[alas_anon]

> and presumed that the student had previously taken "C++", and before
> that had taken a variety of other programming and theory classes, working
> in Pascal, assembler and C, at the least.

Doh!

I'm a teacher also. I have had this problem. You should first check the syllabii and try to determine the student's background. Even then, don't believe that the previous teachers have taught the curriculum.

There's nothing more heart-wrenching than walking into class and expecting to teach the course, only to find out you have students who are not prepared to learn the required materials. It also makes me look "unprepared" when this happens, because I have prepared to teach the syllabus and the students are not at that point of development. When this happens I stall the first class by asking them questions (it's an "oral quiz") and then I quickly rewrite my class plans based on their existing knowledge.

I have never complained to other teachers about this. I normally just drop back and punt. I want to stay on good terms with the other faculty and not start a war. I believe teachers need to stick to the content of the syllabus and if they deviate, it should only augment the course and not ignore it. If a teacher has a disagreement with the syllabii curriculum, they need to lobby to change it rather than just ignoring what it is trying to do. Teachers need to row together to keep on course (pun, haha).

Use the IDE ... and automated tests

[buzmeg]

Unless you are specifically teaching a Unix class, an IDE is really the only good way to get a useful programming environment on Windows. You know, Windows, that funny OS that runs on 99% of the x86 laptops that students now have.

Using Eclipse, for example, allows all of the students access to JUnit and CVS via a consistent interface.

The biggest shock for most of my students was automated testing. Projects had a base set of tests that ran automated up until the deadline. After the deadline, I would run an extra set of tests to make sure that they were solving the problem rather than just writing to my tests.

All students had to do was check correct code into the CVS repository and the automated testing system would take over from there and produce a web page with the test results. Of course, creating correct code was always the trick ...

As a teacher already

[fenux]

I'm a teacher for 5 years already and i lecture courses in java, LAMP, linux and some other stuff depending on the demand. I can speak from experience when i say the following: When you are teaching students which have already had course in Microsoft Visual studio (Visual basic) You will have a hard time arguing with your students(they gravitate to lazyness). Even though, we teach the first year using a simple text editor for all of the obvious reasons: somethinmes you need to now some things by heart. The years after that we use netbeans, the all in one IDE. When using a simple text editor and a command line you will never get as far (at first sight) as the IDE crew, but i'm convinced that in the long run they will have a better understanding. You shouldn't try to teach advanced topics that requires an ide thinking about bigger programs, enterprise technologies, writing unhuman readable xml formats etc... the main thing to remember is not about the language or the ide itself its about grasping the concepts and a good teacher is able to explain them without a language on a chalkboard.

Re:vi/emacs as the IDE

[jonadab]

> Vi and emacs are to an IDE what a Ford model T is to a 2006 Lexus.

I won't talk about vi, but this is a terrible analogy for Emacs. If an IDE is a 2006 Lexus, then Emacs is the car from the movie Batman Begins. It's much more intimidating and harder to learn how to use, but under that hard exterior there is all sorts of functionality that you previously never realized was possible.

Re:I would say IDEs

[nblender]

I've been developing software for 25 years. I hate to break it to you but Emacs is an IDE. I don't get all you emacs kids. I've been using 'vi' for most of my conscious life. I use 'grep' and 'man' to look up types and API's. Recently my corporate overlords forced fed an IDE down my throat but my productivity returned once I determined that it was calling gcc, g++, gdb and gprof.

Re:Go with what they are familiar with.

[Anonymous Brave Guy]

COBOL is still used heavily in industry, with 80% of the world's codebase written in the language, especially in the financial industry.

Would you care to cite a source for that incredibly high number?

Re:Go with what they are familiar with.

[SamLJones]

Maybe something in between would be appropriate. Instead of a full-fledge IDE or barebones vi/notepad, try a text editor with syntax highlighting (like TextPad or NotePad2). Helps with those easy things like unclosed braces, but leaves you to do the more in-depth debugging. Also gives line numbers (not so with notepad). I live on line numbers...

yes to both

[ayounge]

I work for a fairly predominate northeastern college that has a good Computer Science Department. Over the past year, we did a bit of research on this subject using our CS1-CS3 classes which were taught in Java.

Nobody in the department liked the idea of teaching kids Java straight from the beginning from an IDE. so instead, we decided CS1 would be kept the same (emacs, vi, basic no-frills editors) for all classes. Then, we decided we would teach two seperate classes CS2 and CS3 using the Eclipse IDE.

The results were stunning. Not only did the students using the IDE write better, cleaner code, but they also enjoyed coding much more. After realizing the painfullness of writing it all out in a terminal-based program, Eclipse recieved a warm welcome from both the students and the faculty. We will be doing the test over again next year with a larger experimental section (maybe 50/50).

So as for your answer to whether or not to use an IDE? I would say the answer is yes to both. I think its important for students to learn how to use a unix terminal, compile code "the long way" and get down and dirty with a no-frills editor. But using an IDE just makes life simpler sometimes (especially in our case), so why not use it. I think that the solution is to do both, and students will be more productive and have a broader range of knowledge.

p.s. sorry for any spelling, im too lazy to use OO.o :-P

Re:I would say IDEs

[BalanceOfJudgement]

When I was interviewing for my current position, they asked me two questions:

1. What is the integral of x^2? You'd be surprised how many MATH MAJORS they interview that get this question wrong (my degree is in Mechanical Engineering, but I learned programming along the way and it is now most of what I do, with some Engineering sprinkled in there). (btw, the answer is ((x^3)/3) + C)

2. You have a real time system collecting data into a temporary buffer and processing this data. It takes .25 seconds to collect the sample, and .8 seconds to process it. Write a program to make sure you don't drop any data.

They asked me to solve this problem on the whiteboard using C, right there in front of them. It had been awhile since I programmed without an IDE, but because I learned to program without ever using an IDE, it wasn't a problem.

On the other hand, there's another guy at my office who started working there doing something else and somehow got dragged onto a programming project.

After a year, he still can't grasp what the devil a pointer is. I'm not saying someone needs to understand pointers to be a good programmer (although it helps you understand what higher level languages are doing under the surface), but the project we were working on required it. He's so used to using drag and drop stuff like Visual Studio and LabView that really comprehending the inner workings of a language for writing efficient code is just too hard.

I agree when you call this a handicap that just doesn't go away - it has alot to do with how the brain first learns to conceptualize programming, and that's a very, very hard thing to un-learn.

Re:I would say IDEs

[BalanceOfJudgement]

" Any learning programmer who makes mistakes that IDEs will catch will also make other mistakes that IDEs won't catch."

The problem is, compiling a program and being forced to fix the error on your own will help you remember not to make that mistake next time.

When the IDE auto-fills something for you, you never really get that lesson. You might go "oh yeah" every time, but it's far less likely that the lesson will really stick.

At least, that's my experience.

Also, being able to put something together using an IDE that is doing drag-drop and autocomplete for you will never really teach you the basics of things like FIFO queues or binary search algorithms.

While these are often already implemented in higher level languages, it's good to know the basics; for me, even using C# where I don't have to worry about things like that, it still prevents me from doing things like searching a list twice when I really only need to do it once, because I might write the code to do that and then go "Oh duh, that's not necessary," whereas the compiler would happily compile that for me.

And there is alot of work where intimate knowledge of those algorithms is STILL necessary. In the end, programming isn't about being able to use a particular language or an IDE, but about understanding what the software is doing, what your algorithms are doing, and how everything fits together.

I have simply found that using an IDE to learn to PROGRAM gets in the way of learning those concepts. IDE's are great for learning LANGUAGES; they are horrible for learning computer science, because they can't teach you how to write algorithms or understand what the compiler is doing.

I think the answer is somewhere in between.

[petermgreen]

A syntax highlighting newbie useable (e.g. notepad like interface) editor with buttons to invoke the compiler (avoiding the need to screw with the command line directly) seems like a bloody good idea.

Full IDEs with powerfull debuggers and pinpoint resoloution error reporting are imo something that should be saved for later.

Re:Me too!

[Abcd1234]

Heck, I consciously switched *to* Vim from Emacs, after using the latter for *years*. Why? Primarily because RSI, particularly in my pinky finger and my mousing shoulder, has become a bit of a problem for me, and Vim allows me to do all things I can do in Emacs (and a few things I couldn't, or at least never learned how to do :) without the need to chord or move to the mouse all the time. 'course, the fact that Vim is lightening fast to start up, works great in GNU screen (which I use to migrate my shells between work and home), and is amenable to laptop keyboards (which have funky modifier key positions) and ssh sessions (which can sometimes mangle modifiers, like meta) is pretty nice, as well. :)

Teaching with IDE or Raw Coding

[lznancy]

If you are teaching an IDE then use an IDE and treat the language as an afterthought. If you are teaching a programming language then teach them the language and then introduce an IDE as a productivity tool if you so desire. Note: IDEs come and go in and out of vogue and if they are vendor specific as may be true in programming shops where the students will work that particular ventor's package, and of cource IDE, may be gone in 6 months. That is not an assumption on my part but an observed fact of life. IDE's do not reflect the raw behavior of the language and more to the point often can and do make underlying assumptions or operational decisions. Being second guessed by a programmer 2 years ago who thougt that feature of the IDE was cool can be an annoying experience at the best and a fatal one at the worst. It is difficult enough to get a clean behavior of a particular language relative to its specification in a bare bones environment much less as an embedded component in a complex IDE. IDE debuggers don't always reflect the true behavior of the program under general hardware/OS conditions. There are also debugging issues, especially in production environments where the IDE cannot be used in many cases. One of the side effects is often the failure of putting in reasonable program logging and debugging statements because the IDE debugger makes them unnecessary. That can leave you holding the bag at 2:00 am. trying to solve a critical production problem without any usable information. IDE's can become crutches in that a basic understanding of the programming process is assumed to be the process behavior of the IDE, especially by a novice. Sometimes IDE environments can be buggy (after all they are just an added layer of programming complexity from an operational standpoint). You don't have to create expert System Programmers with all the nuances of hardware/assembler/compilier specifices, just give them a basic development environment that can edit/compile/build the basic language for the available hardware/os. After you've gotten them working with the basic language give them the option of using an IDE but have some work that is independent of the IDE always included in the exercises for the rest of the course. If you don't want to be pedantic then after the initial introduction make the non IDE related exercises extra credit. There is nothing wrong with an IDE as a tool, but that is all that it is a tool to managing the programming environment. What counts is what actually ends up running on the hardware and the student's basic understanding of it. Consider that a student properly exposed in this manner can then move from one IDE to another and even work when necessary without one. Basic programming practices (Structured logic, Object Related Design), and a real understanding of the basic language behavior relative to the state machine coupled with some workable knowledge of the standard associated libraries goes a long way to building a competent programmer.

Same problem, different field

[peacefinder]

My father was a community college professor in a technical subject. In his case, diesel engine service. The particular course in which this incident took place required students to tear down and rebuild a variety of fuel injectors, then hook them up to a test stand to prove they operated correctly and held under pressure, then adjust them on the stand to the proper flow rates.

One particular kid just could not tune his injector right. He could tear it down, rebuild it, and hook it up to the stand, but when it came to adjustment he just couldn't get his first injector to come into line. Adjustment was a simpe matter of turning a screw: one way for more fuel, another way for less. Eventually, my dad just stood there and watched the kid work. Eventually dad had his eureka moment that revealed the problem. Being an old-school industrial instructor, he just grabbed the guy by the wrist, pulled him away from the test stand, and pointed him at the wall clock.

"What time is it?" my dad asked.

The student tried to look at the digital watch on his wrist, but dad's wrench-hardened hand had his wrist clamped tight and covered the watch. The kid looked at the analog wall clock again, and couldn't say what time it was.

He couldn't read an analog clock. He didn't have know what was meant by "clockwise for less" and "counterclockwise for more" and had been too embarassed to ask.

Sometimes the basics really matter.

Old School

[Sven Tuerpe]

You might want to read this short article: Musings of an "Old-School" Programmer by Stephen B. Jenkins. I just found it in the May issue of Communications of the ACM. He describes how he works without an IDE and whay he thinks it is the best way of working for him.

students need greater depth of understanding

[wireloose]

As a CIO and IT manager for nearly 2 decades, I have to comment that I am appalled that many young programmers in recent years are clueless about text editors in general. I have found with employees in the last 10 years, the "Windows" generation if you will, they use notepad on occasion, which has limited functionality, and when developing on Unix/Linux systems, they are completely useless. A number of systems that we maintain are slimmed-down systems. The development of apps for these happen on larger systems, and after testing, the apps are moved to the slim systems. I've had to dedicate a lot of money to training resources for these newer hires so they can edit even a simple text config file... We now prefer knowledge of vi as an entry level skill. And if someone claims they have it, we test them.