Slashdot Log In
Should Students Be Taught With or Without an IDE?
Posted by
Cliff
on Sat May 20, 2006 10:50 PM
from the why-the-zero-sum dept.
from the why-the-zero-sum dept.
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?
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Not at first (Score:5, Interesting)
Re:Not at first (Score:4, Insightful)
I would agree with this. I think you can't be a professional programmer without knowing what goes on under the hood. On the other hand, you can't be a professional programmer in a language like Java without mastering one of the better IDEs.
Modern IDEs like Eclipse and IntelliJ IDEA, by making it easy to follow the relationships and jump around the code, permit a more modular, granular style of development than you get using a text editor and opening up one file at a time. And these days I won't even hire somebody who doesn't know and use the automated refactoring tools if their language supports them.
Of course, I also won't hire somebody who can't write reasonably correct code on paper. So yes, do both!
Re:Not at first (Score:5, Insightful)
If you go the non-IDE route, I still think vi is not the way to go. I (have to) use it all the time when sys-admin-ing systems, but for developers there is no reason not to use something like gedit, nedit, etc. Giving them vi is a guarantee for your students to hate sw development.
And personally I would spend one lesson on CLI based compiling and linking of 'hello world', to show what happens under the water of an IDE and then I would quickly move on to something like Netbeans.
Re:Not at first (Score:4, Insightful)
I think emacs is a better editor to start off with than any of the others suggested so far. Here's why:
Easy to use basically in X mode since it has menus, etc. You can save and quit without knowing c-x c-s c-x c-x at first and other useful functions are available via the menus.
Indenting! Emacs teaches us what good code looks like because hitting the tab key puts the line in the right spot. If we're talking python, this is a little different, but C, Java, etc. you need to be bashed in the head with good code style when starting off.
Why jump into a different editor that is just as easy to use as emacs in seperate window mode (or even just XEmacs) when you get all this with the integrated debugger, split windows, indenting, etc?
I am not trying to start up a vi vs. emacs debate because I myself use both editors (I know, blasphemy) when it suits the purpose (vi is good for quick edits, macros; emacs is good for development, debugging; I can go on and on). I am just saying that emacs is totally scalable in terms of ease of use and it is a good editor to start with.
... 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.
Re:... Yes and no (Score:5, Insightful)
I taught college level math (trig through intro to calculus) back in the '80s and the same debate raged with regard to using calculators. If I was teaching arithemtic, I would argue against using calculators since the whole idea is the class is supposed to be about learning simple skills like add, subtract, multiply and divide. If I'm teaching a higher level subject like trig or calculus, I'd say using calculators is great because it allows the students to concentrate on the concepts and not get bogged down in the arithmetic. Hell, when I was working on my MS I used an IBM 5100 running APL to do a bunch of the matrix manipulations for my abstract algebra class and the prof thought it was great since I wasn't spending hours row reducing matrices to get eigenvectors and eigenvalues.
I would argue that the same principle applies here. Higher level classes should encourage the students to use an IDE and higher level languages since the idea is to teach them concepts like data structures, complexity theory, numerical algorithms, etc. Introductory classes really benefit from having the students flail at things like compiler errors and trivial logic errors that a good IDE flags so they understand how little a computer can do until someone programs it. In between, the students need to be exposed to an IDE in a way that makes the transition itself a learning experience and ties in with software engineering, tools and the whole mess that Fred Brooks charaterized as accident vs. essence.
I'd also like to see a class that has students solve a problem using a programming language that's appropriate for the task and one that isn't (e.g., COBOL for a CGI problem) just so they also get some understanding of how using the right tool for the job makes a difference and the problem domain for a given tool is limited. This is probably beyond the scope of the original question.
Cheers,
Dave
Re:... Yes and no (Score:3, Insightful)
Without (Score:5, Insightful)
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.
Why hate MS? (Score:3, Insightful)
Why hate Microsoft? They should have some great debuggers - they're in the business of writing tens of thousands of lines of source per day, some of which isn't going to be perfect. They've got the
At least teach them how to use a debugger (Score:3, Insightful)
You'll give your students an lesson in frustration if you wait until later to teach them how to debug their programs.
I recently took a college course on C, and I wa
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.
Re:depends on what you want to teach (Score:3, Interesting)
Why bother? (Score:4, Insightful)
Re:Why bother? (Score:4, Insightful)
What I'm describing is a simple read-write-sleep loop. It can't possibly be too hard for someone who's supposed to write a working program on his own as an assignment.
Because knowing vi or some other Unix text editor has nothing to do with knowing how to write C code ? The requirement that you had to use a pre-installed editor in the server was simply stupid. Unless, of course, it was meant to inspire such solutions.
A stupid man walks through a rock. A smart man walks around it. An engineer builds a hydraulic arm to move the rock aside and walks where it used to be. When all is said and done, it's the engineers that are movers and shakers, everyone else is simply along for the ride.
The point ? I'm not really sure. I guess it's that an engineer, including a software engineer, is supposed to have a mindset of seeing challenges, not problems. If someone tells you that you must use Vi over SSH to make a program, you don't bitch and whine - you work around the problem. That's what makes you and engineer - you don't complain about problems, you solve them. That attitude is more valuable than any particular skills, since without it, those skills don't do you any good.
I doubt very much any of those are going to become programmers, even if they somehow manage to graduate. If they can't get their code working now, why would they magically achieve that ability somewhere in the future ?
what do you really want to teach? (Score:5, Insightful)
- what do you want to spend your time teaching? Every class minute you spend teaching vi or emacs is a minute you're not teaching the programming. Every assignment you assign to practice vi and emacs is an assignment that can't focus as much on the programming
- what does the college expect someone who passes your class to know? Are they expected to know how to use an IDE for the class that has yours as a pre-req?
- which gives more value to your students? while learning an archaic text editor might be handy, learning to make the most of an IDE might serve them better - knowing how to set breakpoints, watches, stepping through code, etc.
I would suggest you pick the method that will let your students spend more time and energy learning to write good code -- and let them use the system that serves them best.
Re:what do you really want to teach? (Score:3, Insightful)
I say no IDE (Score:3, Insightful)
The course is taught using an IDE which did make it easier for most of the students, but as a result no body even knew javac existed.. as far as they were concerned they clicked a button and it magicaly was compiled.. while some would call this good decoupling, what it showed for me is that people ended up completly ignorant of the underlying implementation... they dont know what the command line options are for the compiler or VM, or that javadoc or jar exist (or the related concepts). It left me playing tech support in class so much that I had to do all my actual coding at home.
This point would be even more important in the case of python given that it can run as an interactive interpreted language and all (I haven't atually finished learning python yet).
The point is that learning without an IDE gives the student better background on how the language works. If you use an editor with syntax higlighting then other than some ease of use there is no real advantage to the IDE.
You mention emacs and vi.. if you are running under a POSIX enviornment then you should really teach without an IDE because it better teaches the principles of the UNIX system ideal (small programs with one purpose). Even if you run Windows it wouldn't hurt the students (and future programmers) to be introduced to the UNIX way of doing things.
hope that helps.
Re:I say no IDE (Score:3, Insightful)
javac, javadoc, and jar are fundamental tools of java programming. Understanding execve()
Teach them without computers (Score:5, Insightful)
Teach them without computers.
No, seriously.
If you really want to teach programming (instead of teaching "using a computer"), start them out on paper and make them actually think about what they're trying to do instead of getting caught up in using the interface. Then have them work in groups using a whiteboard, and don't let them test their code until they've all agreed that it's correct. Teach them to look out for their own mistakes, and the mistakes of others, rather than counting on the computer to do their thinking for them.
There was a definite advantage to the old submit-a-deck-of-cards system, in that mistakes were annoying and you worked hard to avoid them. To do this, you had to really think about what you were trying to accomplish, how you planed to do it, and what might go wrong. In other words, you were really learning to program.
On the other hand, with highly interactive environments (which are extremely useful once you know what you are doing) beginners are all to tempted to fall into a trial and error loop until they get something that "works"--which is to say, it happens to produce reasonable results for whatever limited test case they are using--without ever really thinking about the program.
Suppose you were teaching flying. Would you start your students out in an advanced aircraft with an autopilot that could take off and land unassisted, and all sorts of doodads to make flying easy--or would you sit them down with a pad of paper and make them work out things like stall speed and fuel requirement problems until they really understood the issues?
-- MarkusQ
Re:Teach them without computers (Score:3, Insightful)
Great way to kill any interest in your course (Score:5, Insightful)
One of the most important things when you are starting out (and, actually, when you are experienced as well, but that's less obvious) is to get feedback on what you are doing wrong as quickly as possible. Don't throw this away lightly.
It's quite easy for students to work very long and hard doing something _completely and utterly wrong._ This does _not_ make them better programmers than if they got immediate feedback on what was wrong; it just frustrates them.
(I spent over a year teaching 100-300 level CS classes, and we actually started with paper-based flowcharting in one intro class, so I'm not speaking hypothetically here.)
--
Carnage Blender [carnageblender.com]: Meet interesting people. Kill them.
Re:Teach them without computers (Score:5, Insightful)
I used to do this in high-school, though. I would write applications down in a notebook one line at a time, then type them all in when I got to my calculator. It could be valuable, but there were many programs that had to be scrapped and re-written because there was an error somewhere in the code and it was impossible to figure out where the problem had arisen.
A tight success / failure loop does help teach people to seek out and find problem areas quickly and painlessly, before more and more code gets committed on top of the bugs, burying them in layers if misdirection.
Suppose you were teaching flying. Would you start your students out in an advanced aircraft with an autopilot that could take off and land unassisted, and all sorts of doodads to make flying easy--or would you sit them down with a pad of paper and make them work out things like stall speed and fuel requirement problems until they really understood the issues?
I'd drop them in front of MS flight simulator so that they would get a feel for what they were going to do. "The maths" generally don't teach a pilot how to recover from a downdraft.
Re:Teach them without computers (Score:4, Insightful)
parent: On the other hand, with highly interactive environments (which are extremely useful once you know what you are doing) beginners are all to tempted to fall into a trial and error loop until they get something that "works"--which is to say, it happens to produce reasonable results for whatever limited test case they are using--without ever really thinking about the program.
I concur, the trial and error method of "write a line of code, try to compile it, fix the compiler error, repeat until program runs, then test an input, if it's wrong make a change, recompile, test an input... etc" isn't really learning how to program (and at worst it's only teaching how to choose good tests). I mean it's kind of like the slowest most terrible implementation of evolutionary programming (highschoolers get a head start, google Lawrence J. Fogel) or a slightly better optimized "one million monkeys" scenario. Maybe it is learning how to program, but it isn't really learning how to be a programmer. Maybe that's a distinction worth discussing.
Not that I'm especially qualified, but this is how I'd teach a programming course: Present the concept, explain the concept, train the concept (this is all face time, auditory, visual learning); assign reading and homework on the concept, test/quiz the concept (student opportunity to take ownership and get special attention, hands-on learning); assign implementation of the concept and then grade the implementation (hands-on practice); repeat until finals week. Homework over short breaks m-w, w-f and t-r with imlementation over long breaks r-t, and f-m assuming two and three per week meetings. Kids love weekends in the lab! (Do they even program in the lab anymore?)
Whether or not the implementation phase involves an IDE or just a text editor shouldn't really have a huge impact on the students' understanding unless one has to spend time teaching the environment -- taking away time that students need spent on teaching and learning the concept.
yes and no (Score:3, Insightful)
My first course in programming was at UMass Boston, which is basically a community college, and we started off learning emacs, then went on to our first cup of java.
It was pretty gruelling.
But now I still know emacs and use it every day, while the java technology (1.0) has changed a great deal.
My point is that if you're going to teach them a tool, use one that will still be useful and helpful later on in their academic and professional careers. Visual Studio may not even be around in 5 years, but most likely, it'll still be around and will use a different interface that they'll have to relearn. Instead, focus on the fundamentals of any IDE, such as compiling, linking, testing, debugging, so that they'll have no problem learning whatever IDE their company uses. In this sense, I think it makes more sense to learn that to compile a program into bytecode or machine code, you have to launch another program that does this (gcc program.c or javac Program.java) rather than just click a Run button and have everything magically happen for you.
This goes along with teaching the fundamentals of programming languages and operating systems rather than preparing them to work in a single specific language or OS and have them out of work in 10 years.
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.
Anti-IDE snobbery... (Score:3, Insightful)
It seems to me that there are two purposes to CS classes: theory and skills aquisition. You'll get plenty of the theory of computer science in your algorithms/data structures/whatever classes. For the CS101s of the world, if you get out of the class without being able to produce a simple program in the language you were using, thats a failure. In the real world, you will probably end up using an IDE, because its a tool which increases your productivity by an order of magnitude and makes managing the complexity of non-trivial programming assignments *possible*. When you've got three classes and two of them were provided by the instructor, sure, Notepad will work for you. When you get to your job and are tasked with adding a simple feature to one file which calls functions from 45 classes, then you'd best have an IDE or a lot of time on your hands to waste. Things like autocomplete, syntax checking (we all make typos or have brain farts, having a little squiggle beneath "if (x = 0)" or "if (!x.contains(y)) x.add(y);y.addContainer(x));" as soon as you type it can save minutes or hours of lost productivity), and integrated debuggers (I use and love print statements, but when you're trying to figure out why a hash function is failing for *one* input halfway through a list of ten-thousand a debugger is worth its weight in gold) are all tools that engineers should be introduced to as soon as possible.
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.
Integrated Development Environment (Score:3, Informative)
I could ramble on about it, but I'll just link you to the wikipedia article [wikipedia.org]
--
NoFluffNews.com: Slash-based site for REAL news. [nofluffnews.com] Template still in development. Seeking intelligent journalists and editors.
Re:forgive my ignorance (Score:4, Funny)
Re:I would say IDEs (Score:5, Insightful)
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.
similarly, as long as they can debug in the IDE, they'll never learn real debugging techniques that the "cold metal", or even just debugging a running server they can't get an IDE into.
They should learn to program as close to the raw as possible. notepad, command line, debugging through prints.
They should learn software development separately, with an IDE, with integrated debugging and complex build systems. Learning to program, and learning to be a good software developer are two separate things.
Re:I would say IDEs (Score:5, Informative)
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 (Score:5, Funny)
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 (Score:4, Insightful)
Why not let students make use of IDE features such as code completion, color coding, et cetera? When they get into the real world, they will be able to use an IDE with these features if they please, why force them to practice on something they won't actually use when they graduate? That's just a waste of time for the students. Sure, some of these IDE features make learning the language easier for them, but it won't turn them into code idiots. They'll still need to understand the language in order to be able to program with it!
Re:I would say IDEs (Score:5, Insightful)
IDEs make programming easier to learn and more efficient. I still don't think he should spend a lot of time integrating it into his class. Tell them about the existance of IDEs and let them figure it out themselves.
Re:I would say IDEs (Score:4, Insightful)
IDE Way - The students will probably be able to develop faster and thus you can progress more quickly through more ideas and thus you can perhaps get more accomplished. Plus they can gain experience with the ins and outs of classpaths, IDE installation, things like that that they'll need to learn eventually anyway for real world Java development.
Non IDE Way - They might get through 4/5ths of the above lesson plan, but on the flip side they'll be closer to the metal, as someone already said and they'll learn to develop good style habits from the start and to debug even when they have no tool to lean on, just the JDK.
I personally would go with #2, but it depends on what you want to set out to accomplish. If you want to get deep into the language, #1 might be the way to go. But if you want to make sure they can truly walk before running, definitely #2.
Re:I would say IDEs (Score:5, Insightful)
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
Hmmm... (Score:4, Insightful)
Also, the lack of a need to get a product out of the door means that you can spend time on things that give a foundation. That educational requirements are different is an advantage. Which firms, for example, would spend three years teaching someone a maths degree? Yet those same firms would gladly hire a mathematician!
Re:I would say IDEs (Score:3, Interesting)
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.
Re:A scary story related to this question (Score:5, Insightful)
The drag-and-droppers solve every problem with ready-made components. They depend on the components provided to them by the IDE to such a degree that they generally are not able to design an actual algorithm. Yes, they know how to make a function, and a loop, or use an if structure, but they can't build a sorting algorithm, or build a data structure in memory and perform calculations across it. For what we do these people are useless.
Here's the rub: most of them have programming degrees of one form or another, and almost all of them have years of experience as a programmer, with adequate references.
We've learned the hard way to make everyone that comes to apply for a job with us take a basic programming knowledge test, where they have to design and implement an algorithm to solve a relatively easy problem that can not be solved with ready-made components (we place no requirements on the solution, other than that it should work), but can be solved by a competent programmer in less than an hour, and we give them four hours to do it. Most of the people that apply are incapable of even getting close to a solution. Some people with years of experience can't even produce one line of code towards the solution (after four hours they literally have nothing at all).
This is why I'm distrustful of teaching programming with IDE's. Sure, use IDE's, but please give them tasks that require them to understand about data structures, algorithms, and actual programming. It doesn't even have to be OOP (from my experience you can teach that afterwards). Just teach them programming beyond ifs, loops and functions. Make them build data storage facilities that use self-balancing trees for quick lookup. Make them implement various sorting algorithms and test their relative performance. Just make them do stuff that demonstrates actual competence.
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:I would say IDEs (Score:4, Insightful)
love,
Anonymous Coward.
Re:I would say IDEs (Score:4, Insightful)
As for the question of whether or not you should use an IDE to teach a language class, I think using a text editor and CLI has the potential to be just as confusing as a bloated IDE. I recommend one of the slim IDEs, such as JCreator LE, Textpad, or Dev-C++. They're all light, do very little work the student, but make sure no one is hunting around for a make file.
Aero