Should Students Be Taught With or Without an IDE? 848
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?
Not at first (Score:5, Interesting)
... Yes and no (Score:5, Interesting)
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 (Score:5, Interesting)
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.
Focus on the goal of the course (Score:2, Interesting)
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.
Re:depends on what you want to teach (Score:3, Interesting)
Emacs and Ant (Score:4, Interesting)
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 (Score:2, Interesting)
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:Not at first (Score:2, Interesting)
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:Go with what they are familiar with. (Score:3, Interesting)
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 (Score:3, Interesting)
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 (Score:2, Interesting)
Re:I would say IDEs (Score:3, Interesting)
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 (Score:5, Interesting)
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.
Use the IDE ... and automated tests (Score:2, Interesting)
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 (Score:2, Interesting)
Re:A scary story related to this question (Score:1, Interesting)
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 (Score:5, Interesting)
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 [irt.org] - 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:vi/emacs as the IDE (Score:2, Interesting)
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:A scary story related to this question (Score:2, Interesting)
> 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).
Re:I would say IDEs (Score:3, Interesting)
Re:Not at first (Score:1, Interesting)
Re:depends on what you want to teach (Score:3, Interesting)
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.
Re:Go with what they are familiar with. (Score:3, Interesting)
Would you care to cite a source for that incredibly high number?
Re:Go with what they are familiar with. (Score:2, Interesting)
yes to both (Score:2, Interesting)
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 (Score:3, Interesting)
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
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 (Score:3, Interesting)
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. (Score:3, Interesting)
Full IDEs with powerfull debuggers and pinpoint resoloution error reporting are imo something that should be saved for later.
Re:Me too! (Score:3, Interesting)
Teaching with IDE or Raw Coding (Score:2, Interesting)
Same problem, different field (Score:3, Interesting)
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 (Score:3, Interesting)
You might want to read this short article: Musings of an "Old-School" Programmer [erudil.com] 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 (Score:2, Interesting)