Slashdot Mirror
Should Students Be Taught With or Without an IDE?
bblazer asks: "Beginning this next school year, there is a strong possibility I will be teaching an intro to Java and an intro to Python course at the local community college. I was wondering what the prevailing wisdom is when it comes to teaching languages - should students be taught with or without an IDE? I am a bit old school and wouldn't mind having them all use vi or emacs, but using a good IDE does have some advantages as well. I should note that the students I will be teaching will have had at least 1 semester of programming in VB or C++." Even though there is limited time in a semester, could a curriculum be constructed to accommodate both methods?
I generally prefer without. My intro CS course (in Java) five years ago was taught using emacs (which I actually didn't like at the time), and part of the beginning of the course was graded on knowing emacs shortcuts. A later course that I was a TA for used BlueJay, and again grading was done dependent on using that IDE.
I am more a fan of letting students choose their own environment. I've been using UltraEdit for a long long time, and I'm very happy with it. My suggestion would be to give students a list of good editor options, but not require them to use any single one. Maybe a later lesson could focus on the debugging potential of one IDE or another (I hate to say it, but Microsoft has some great debuggers). My experience, though, is that the main issue for students is what they're writing, not how they write it.
Bravery is not a function of firepower.
~J.C. Denton (Deus Ex)
no.
as long as they trust the editor to catch their mistakes, they'll never actually learn to avoid them; they'll simply let the IDE be their guide and never learn it.
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.
"But remember, most lynch mobs aren't this nice." (H.Simpson)
-- Joe
Why have one at all? Unless your class is on the specific IDE or "Software Development Techiniques", why chain them to a specific technology? Let your students figure out how to run the damn editor. If it wasn't so tedious, I'd say have your students turn in assignments on paper. You are teaching programming, not a program, no matter how community college you are. Give your students a chance to figure something out for themselves and they will become smarter.
Did you ever notice that *nix doesn't even cover Linux?
There are lots of factors that will probably make this decision for you:
- 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.
I am a high school student.. I'm currently taking (and often teaching more than the teacher ) an AP Computer Science course which, while actualy about the concepts (OO Principles, Algorithims, Data Structures (well they _should_ be included), etc.), is taught in Java.
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.
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
BTW, given the way the original question was asked, I would have just answered "yes".
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
They that can give up essential liberty to obtain a little temporary safety deserve neither safety nor liberty.
Ben
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 : Meet interesting people. Kill them.
"Since you mentioned that they already have experience with VB or C++ (and I'm assuming when you say C++, you mean Visual Studio), just go with what they already know."
I would suggest the oppsite. Go with something new. If they have already seen various IDE's in the past then go with a stright text editor. The worst you could possibly do for a student is lead them to believe there is only one way. There is nothing like the experience of being confronted with that blank screen, it builds competence.
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.
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!
debugging through prints.
Now I remember why I hated programming.
I'm going to disagree with the parent and say IDEs. Although I think his point about software development and programming being two separate things has merit.
They should - although you shouldn't assume - have already been taught how to programme. Are they're going to use an IDE when they leave college? You are supposed to be training them for the work place.
First and foremost - teach them good practice, tight simple modules with good comments.
Introduce them to an IDE, show them a couple if you've got time. Assign them tasks using the IDE. Go through the source code line by line. (starting at the end?) Write some really crappy code and get them to fix it using the IDE. Chuck out the IDE and get them to fix more crappy code using whatever masochistic tool you like. Have them debug each others work.
What I'm saying is try to replicate your experiences of the real world as much as possible. Just because IDEs weren't available when a lot of us were being taught doesn't mean we have to perpetuate a crappy situation.
Teach them to be efficient and fast - show them how to use what's available to them so they're not reinventing the wheel.
Ok, now that I've written efficient, we're going to have people argue that IDEs don't produce efficient code. One word... Java?
Ronan
I still think that you are wrong. IDE's have their place in beginning CS classes. You shouldn't be screwing around in vi/emacs trying to figure out how to type at all. Command line proves nothing. Some of the best programmer's a know use both GUI's and command line. I personally use almost all command line tools, but that's from personal choice. I don't think the youngsters should be sitting around scratching their ass trying to figure out vi, gcc, or make when the class is about learning a frikken language. They can do that in round 2 after their appetite for PROGRAMMING has been whetted
love,
Anonymous Coward.
As a CS major, I say mod this AC up. He has a great point in that a programming class should be about learning the language, not VI, EMACS, or screwing around 0 ith the command line. The parent's post would be a good way to scare off future programmers.
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
Please stop hurting America -- Jon Stewart
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.
Browsers shouldn't have a back button!! It's all about going forward...
I couldn't disagree more. Searching through directories is time you wasted, not time you spent learning a language. You learn a language by using it and by reading about it - both of these tasks are made easier by a good IDE. Javadoc integration makes APIs discoverable, just like well designed user interfaces are discoverable. You don't ever need to leave the IDE to read the documentation, because it's right there. Of course auto-complete helps when you're in doubt, but there's nothing wrong with that. There isn't much merit to knowing a billion function prototypes by heart, those are details you shouldn't worry about, bigger things are much more important. And stuff like for example the highlighting of other instances of a selected variable is just crucial when you need to understand a large piece of code written by somebody else.
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.
Switch back to Slashdot's D1 system.
I work at a small software development company, and am often involved in the hiring of new programmers (for Delphi-based software projects). You can roughly divide them into two categories: the ones who know their stuff, and the drag-and-droppers.
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.
I would suggest the oppsite. Go with something new.
I'd suggest you both fell into the trap posed by an incomplete question. Teaching someone to use an IDE and teaching them not to use an IDE are not mutually exclusive.
A good programmer should know the basics without distraction, and also know when to save time by using an IDE.
I think that's a tougher call, really. I learned every language I currently use (and HTML) doing bare to the metal programming in Pico or JEdit, etc. I think it served me well. I personally think there are two ways to look at it.
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.
Why the need to choose between paper and computer? Why the need to choose between vi/emacs and IDE? This is all nonsense. First thing is to decide what knowledge is student expected to display. If the sudents needs to display good organizing skill, mental discipline, good memory and expert knowledge of problem domain, by all means push them to paper or vi/emacs. If you want the students to display the knowledge of grammar, whether in natural or synthetic language, then remove the obstacles that require so much more. You might not want to give students an IDE with RAD tools integrated, but any GUI text editor with syntax highlight should do, just like any word processor with spell-and-grammar checker will do for texts.
First step in school of writing is to master the grammar and style. This can only be achieved if the student doesn't have helpers (live or automated) that clean up his/her mistakes. The student must be able to proof-read own texts, spot mistakes and fix them. No need to to this on paper, but it certainly shouldn't be done with F9.
First step in school of programming is to master the grammar and style. This can only be achieved if the student doesn't have helpers (live or automated) that write plumbing code for him/her. The student must be able to read his own code, understand it and write it from first "public class", to the last "}". No need to do this with vi/emacs, as there is not context help, no language reference a single click away, no drop down context menus to insert class member names. However, there should be no magic Alt-Whatever key to create complete class construct all ready for inserting the code into members, let alone some magic RAD builder. These things hurt students, not help them.
Once the students are past the introductionary stage, you can start moulding them. Once you know your natural grammar and style, you can focus on what do you want to write. Once you know synthetic language grammar and constructs, you can focus on whole applications with GUI and all. Just like established columnist writes a column and presses that magic F9 button to catch anything he/she missed, the programmer clicks couple of buttons to write that plumbing that holdes the logic together. But stay away of tools that will do this for you when you don't master those things yet.
One thing is to lecture basics of programming. IDE can be used for all the help in writing the code, but it shouldn't be abused to write code constructs. When the students know how to write these basic construct by themselves, then comes the time to start lecturing the use of IDE and the tools that it provides. Students should obtain complete knowledge from the basics of how to write in plain editor, all the way to knowing the tools that will make them productive when they go out and start doing this for life.
It's similar with algebra. As a student, I had to display knowledge in three areas:
where I had to display the knowledge of axioms and theorems
where I had to display the knowledge of using the theory on short practical tasks
where I had to display the knowledge of solving large problems in as efficient ways as possible
Catch was that you couldn't take tests 2 and 3, if you failed test 1, and you couldn't take test 3, if you failed test 2. It was simple bullshit filter, that worked perfectly.
Programming is just like that. You should first understand the syntax (statemets, operators, how do they fit together), only then you can start writing short snippets (reading, writing, calculating, sorting, ...), and only after you know this, you can start thinking about writing complete application with GUI (using data binding, database access, designing usable GUI, ...). Each step takes you further to the point of useful knowledge, but you just can't skip any of them. Lecturer just has to decide on the right tools for the right level and don't let the students skip steps that are needed for complete understanding.
To boldly invent more hot water.
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!
Wikileaks, no DNS
Don't jump out and mark this as Troll, but...
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.
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!