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

I would say IDEs

[Navreet]

They'll help students avoid silly mistakes, e.g. if they're trying to use a variable that is out of scope it might not autocomplete, etc. So, they might catch some mistakes and learn to avoid them before they hit compile.
I would let the students chose... Ofcourse, you might have to teach them how to create a project with an IDE, too.. [instead of just supplying the make files].

Re:I would say IDEs

[acroyear]

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.

Re:I would say IDEs

[IgLou]

I would say they need to be taught both. The IDE conceals certain activities (checkin/checkout/version control/branching) that students should become familiar with and the also need to function without these. I work in Configuration Management and I've seen people come in fresh into the field that have no understanding of even version control (or builds, shudder)... that's a bit rough.

I think to survive programming in the industry you need to know how to function with the IDE for larger shops with detailed processes and for smaller teams or environments where none would exist. Now that said, I think even the smallest of development requires some type of version control by a repository it should be something everyone knows how to do. That said, I wouldn't expect anybody trained in programming to come right out of school knowing how to implement a development process integrated with version control, QA, and software builds. But you should have some understanding how this all impacts your day to day work.

Oh and FYI if you look at doing this with Visual Studio 2005 and Team Foundation, you should introduce your students to defect tracking and QA processes to because it's all integrated there. Anyways, just my 2 cents.

Re:I would say IDEs

[acroyear]

anonymous asshole, i've been in the *real* world for 15 years. i've seen so many slaves to IDEs who can't design or write real programs for shit that i absolutely dread interviewing new candidates.

i want people who know how to program, for whom the IDE is a tool to make their accurate and creative thought process real. instead, i get people who don't know shit and let the IDE do all the thinking for them.

the IDE is a great tool for software development. for learning to program, it creates a handicapp that never goes away.

now if you really want any respect for your own opinion, sign your fucking name to it.

Re:I would say IDEs

[rossifer]

no.

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

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

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

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

Regards,
Ross

Re:I would say IDEs

[Anonymous Coward]

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

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

Re:I would say IDEs

[ronanm]

debugging through prints.
Now I remember why I hated programming.

I'm going to disagree with the parent and say IDEs. Although I think his point about software development and programming being two separate things has merit.

They should - although you shouldn't assume - have already been taught how to programme. Are they're going to use an IDE when they leave college? You are supposed to be training them for the work place.

First and foremost - teach them good practice, tight simple modules with good comments.

Introduce them to an IDE, show them a couple if you've got time. Assign them tasks using the IDE. Go through the source code line by line. (starting at the end?) Write some really crappy code and get them to fix it using the IDE. Chuck out the IDE and get them to fix more crappy code using whatever masochistic tool you like. Have them debug each others work.

What I'm saying is try to replicate your experiences of the real world as much as possible. Just because IDEs weren't available when a lot of us were being taught doesn't mean we have to perpetuate a crappy situation.

Teach them to be efficient and fast - show them how to use what's available to them so they're not reinventing the wheel.

Ok, now that I've written efficient, we're going to have people argue that IDEs don't produce efficient code. One word... Java?

Ronan

Re:I would say IDEs

[Anonymous Coward]

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.

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.

Re:I would say IDEs

[MimsyBoro]

I would just like to back the parent up.

And although it might be considerd karma-whoring I would like to post a link to a great article: Does visual studio rot the mind?.

I think this is true, although the author of the article does agree, he then continues to say that VS is a necessary evil, well I guess he just hasn't met emacs yet (or vi for you vi-fans out there)

Re:I would say IDEs

[aero2600-5]

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

Re:I would say IDEs

[moonbender]

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.

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:I would say IDEs

[TrekCycling]

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.

Re:I would say IDEs

[acroyear]

not saying what you said isn't insightful, but what you said is like saying people should type essays without a spell checker.

Every English teacher in the world would love it if spell checkers went away. Why? because then kids would have to actually learn how to f'in' spell!!!!

The spell checker has already created the handicapp. Especially as the spell checker doesn't get them to read for the correct they're/their/there etc., because they're all *spelled* correctly. (Yeah, Word supposedly has grammer checking, but its been wrong on my writing multiple times).

Re:I would say IDEs

[demeteloaf]

As somone who just went through a couple intro to programming classes (stupid university not giving me credit for them), i have to agree that this approach is probably the best one out there.

The very first experiance everyone has with code here is simple text-editor/command line, coding, compliling, and running. After about a week-ish of writing simple "hello world" programs, they are introducted to a relatively bare bones compilor JCreator (basically it has syntax highlighting, auto-indentation, and project building, but you still have to compile the code and wade through the error results yourself.)

After students passed that semester of basic coding, the next semester introduced IDE's with more features, like eclipse, which does fix simple errors for you and basically make the coding go faster so the students get a more general view on whatever is being taught.

It seemed to me this philosophy worked the best, when students were just learning, they had to figure out what was wrong and catch it on their own, but as they got more proficient, they were given tools that did the basic stuff for them.

Re:I would say IDEs

[DahGhostfacedFiddlah]

What the hell is with these comments? There's a comment about not using IDEs, and then a billion after it complaining that you "don't need emacs", "don't need vi", "don't need notepad".

Of &$*%ing course you don't need that! What you do need is an editor. It doesn't matter which one - it can be edlin if that's your fancy.

People should be free to choose their own devel environment, not taught it. Posters complain about having to learn emacs in a programming class - how long do you think it takes to learn the ins and outs of a freaking IDE?

Let people work with any environment they want - especially beginners. If you're building in notepad and someone else is using Word and saving as text, at least you've got that basic idea that the IDE is not the language. If all of the programming you've ever seen has been through one interface and one interface only, then you will - even subconsciously - have a ton of false assumptions about how it is that programming actually works, and you will be less prepared for moving to a different environment.

Basically, monoculture == bad. Especially for something as ubiquitous and simple as a text editor.

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.

Re:I would say IDEs

[Kluenitou]

I think this is slashdot gone way too fucking far.

Agreed. One thing that I've noticed as a Computer Science major and avid slashdot reader is that most CS guys tend to make things harder for themselves and others that they should be. I don't see any valid argument against using an IDE except to make life more difficult. My best guess is that programmers that grew up without the use of an IDE want newcomers to suffer as much as they did by using emacs, vi, etc. when an easier solution exists. It seems like a sophomoric "I suffered, now I'll make those that come after me suffer" situation.

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!

Integrated Development Environment

[caryw]

An integrated development environment.

I could ramble on about it, but I'll just link you to the wikipedia article
--
NoFluffNews.com: Slash-based site for REAL news. Template still in development. Seeking intelligent journalists and editors.

Go with what they are familiar with.

[Fredwick.com]

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. If it were me, I'd stick them with an appropriate IDE for whatever language(s) you end up teaching. Speaking as a community college student myself, you should realize that unless you live in a predominantly technical area, most of your students students are going to be more comfortable learning with an IDE than with a blank vi screen. If you were teaching at a university, that might be different.

Re:Go with what they are familiar with.

[Anonymous Coward]

"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.

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.

Re:Go with what they are familiar with.

[KingMotley]

Go with the IDE. Unless the purpose of the course is about how to get things to compile, and how to use outdated editors (Like vi), dropping them on the command line will just turn your course from Java/Python into a unix/linux 101 class instead. Overburdoning your students with cryptic command line syntax (For a specific compiler and editor -- of which they will probably use neither of ever again) doesn't really do your students that much good, and lands up detracting from them learning the language itself.

I'm all for teaching basic command line skills to those that actually want to do it for a living, but that's a different course entirely.

Re:Go with what they are familiar with.

[samkass]

Vim 7 was released less than 2 weeks ago. I'd hardly call that outdated.

Yeah, and COBOL2002 isn't outdated, either.

Re:Go with what they are familiar with.

[Itchy Rich]

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.

Re:Go with what they are familiar with.

[StarvingSE]

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

If you are a proficient COBOL/mainframe programmer, you will not have a hard time finding a nice high paying job for life. So no, it's not outdated by any means.

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...

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

[dubl-u]

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!

Re:Not at first

[wwwillem]

Unfortunately on Linux, the Editor should be vi...

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

[EchoNiner]

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.

... 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.

Without

[Hegh]

I generally prefer without. My intro CS course (in Java) five years ago was taught using emacs (which I actually didn't like at the time), and part of the beginning of the course was graded on knowing emacs shortcuts. A later course that I was a TA for used BlueJay, and again grading was done dependent on using that IDE.

I am more a fan of letting students choose their own environment. I've been using UltraEdit for a long long time, and I'm very happy with it. My suggestion would be to give students a list of good editor options, but not require them to use any single one. Maybe a later lesson could focus on the debugging potential of one IDE or another (I hate to say it, but Microsoft has some great debuggers). My experience, though, is that the main issue for students is what they're writing, not how they write it.

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.

With.

[Telastyn]

Part of practical language experience [since you're not actually teaching programming] is learning to use a/the common IDE.

Why bother?

[illuminatedwax]

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.

Re:Why bother?

[ultranova]

A good idea but I what your are describing probably is harder than most of the entry level programs I had to do.

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.

If you really want to be a decent programmer then why spend money to learn how to copy and paste?

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 can't recall how many times I was offered money to turn over my code that actually worked. It would have been easy to just do that then actually work at a shit job on campus but the fear of getting caught along with the moral instict of not wanting to "help" a future programmer be a POS made me decide not to do that.

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?

[hazem]

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.

Re:what do you really want to teach?

[AuMatar]

I'd think the first point is more a slam at IDEs than text editors. IDEs require a lot of knowledge to use- teaching the debugger, how to create projects, etc. Meanwhile, everyone has used a text editor. They can just use notepad if they want. If you want to focus in on the programming (the right choice, IMO) just tell them to use a text editor and let them figure out IDEs if they want to.

Free is good

[LihTox]

I'm completely naive as far as IDEs are concerned, but is there a freeware IDE available for these languages? It won't matter while they're in school, maybe, but if they become comfortable with a program, and then leave school and find out the program runs $900, they will be in a (minor) bind if they want to do some programming on their own. (I'm thinking of the parallel case of people working with Matlab and Mathematica; yes they are great programs to work with, but as an unemployed physicist I can't afford either one.)

I say no IDE

[donaldGuy]

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.

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:I say no IDE

[pchan-]

Are you sure you don't want the students building their own transistors and generating their own electricity? How will they learn? Welcome to reductio ad absurdum.

javac, javadoc, and jar are fundamental tools of java programming. Understanding execve() and assembly programming are not. Using javac is the minimum you need to program java in any environment. It is in fact all you need, unless you want additional tools. An IDE is nice to have, if you're into that kind of thing, but it is far from a requirement for java development. A student who has learned the IDE and not the fundamental tools has been done a disservice by a poor teacher.

Teach them without computers

[MarkusQ]

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

[Anonymous Coward]

Some people (like me) learn by reverse engineering everyhting, and that requires trial and error, we need to see what works and what doesn't, only then can we understand why. Your suggestion excludes those people. Yes it's true that most students have to be taught the way you describe, but you are excluding the most skilled ones, those who have the highest chances of scoring high in the real world without cheating.

Your analogy is also wrong: you can experiment with software as much as you wish as the chances of breaking anything are slim (unless you are developing an embedded operating system and accidentally erase a firmware which cannot be easily replaced or something), but if you try to fly an aircraft all by yourself and crash, the craft is lost, and probably so is your life.

Re:Teach them without computers

[cgenman]

The two problems with this is that it is difficult to catch errors and discourages test-based development methods.

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

[Puff Daddy]

Teaching without computers has its merits and its limitations. I think the happy medium, for intro courses at least, is to ask to see pseudocode. It teaches the students good programming principles while not chaining them to any one language or program. Of course, also require an executable program, but only after decent pseudocode has been submitted. This can extend to mid-level courses and understanding various data structures. This is where the variety of tools should be introduced. Introduce an IDE, or two. Begin allowing projects to be submitted in the student's chosen language. By the time students have reached the advanced level, they should be able to choose the best tools for the job. By this time, most of the non-majors will have ceased their study of CS, and most of the majors who never belonged there in the first place will have quit. Grade the remainder on their results, inquire about their methods. If you feel that their methods are holding them back, provide guidance.

Re:Teach them without computers

[David Rolfe]

When I was in CS in the mid-90s we took Theory of Computing (no computers) before we took Intro to C, Algorithms, Data Structures, etc for exactly this reason. Professors could presume we knew some actual fundementals (and unlearned all the BASIC and Pascal we'd done in grade- and highschool). We wrote software at terminals in a computer lab or via SLIP from home (with pico, vi or emacs). We turned in from the shell prompt. Same for Assembly and later, Unix Administration with Perl (first edition Camel book was the text :-p). It wasn't until Intro to Computer Graphics (description: "This course isn't how to use PhotoShop, it's how to write PhotoShop") that we where using IDEs.

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. :-D Just my two cents.

yes and no

[coshx]

No to Visual Studio, but yes to an IDE. Well, emacs and vi can be thought of as IDE's that is.

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.

If you think "Hello, world" demands an IDE...

[Darth Liberus]

Then by all means, teach with an IDE. Otherwise, the KISS rule would say "give them a choice of text editors and teach the basics."

IDEs are insanely useful when working on large projects, and should be introduced towards the end of the class, but IMHO if you use an IDE from the start you're going to end up with a bunch of students who understand the IDE instead of the core concepts they need to know.

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:... Yes and no

[DaveAtFraud]

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

Why hate MS?

[Kawahee]

I hate to say it, but Microsoft has some great debuggers

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 knowledge and expertise, and most of the people working there are a lot like you and I, it's just that their business ideology is to mostly focus on the desktop market, and Windows etc reflects an operating system for a normal person to use.

You can also thank them for making an awesome IDE.

Re:Why hate MS?

[Danga]

You can also thank them for making an awesome IDE.

I agree. After I left school I had almost no experience programming for windows (not a bad thing). But it was VERY nice to have VS since my first job was programming windows apps. I had used UltraEdit all through school and (while UE is awesome) it was nice to have a built in debugger as well as all the other goodies VS has. It is seriously the 2nd MS app I am happy to use (the other not being an app but Windows XP Pro is pretty damn good too IMHO).

Re:Why hate MS?

[Hegh]

Oh, I don't hate Microsoft, I just wish that some other people (read as "open source" or at least "free") could come up with debuggers that are as friendly and functional as theirs. That said, though, I've never actually tried their J# IDE for anything other than editing (because it does some nice syntax highlighting and code completion). I used the command line to compile, and never touched their debugger.

No Emacs either

[metamatic]

What I see in people that turn how to program with an IDE is they are tied to that IDE, they dont want to use another. Its like pulling teeth to get them to switch. The other problem they have is they know nothing about the compiler.

Same is true of a lot of people who use Emacs too much. It becomes impossible to get them to even try another program. Introduce them to some new concept like, say, an N-dimensional sparse matrix manipulation system with typed data cells, and they say "So, is there an emacs interface for this?" They read their e-mail in emacs, they read news in emacs, some of them even use emacs as a web browser and shell.

So I'd say start with a text editor. Something simple. For Java, get them at least as far as building a small project with a handful of files into a jar and running it. Then, you can say "So, now you get how it works, here's a tool that can save time and effort..." Then you introduce an IDE. And also Ant, ideally.

Also, I'd say don't force the students to use a particular IDE or editor. That's not the point of the class. If they want to do the assignments using NOTEPAD.EXE, let 'em.

Great way to kill any interest in your course

[jbellis]

Remember, submitter is planning to teach _intro_ courses to Java and Python.

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.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:forgive my ignorance

[Anonymous Coward]

Dumbass. Integrated Drive Electronics interface, one of the most popular hard drive interfaces. If you or the author of the article would have simply used Google, you would find that information and the author would know that using IDE sucks and SCSI is like way better.

At least teach them how to use a debugger

[Ichijo]

"Maybe a later lesson could focus on the debugging potential of one IDE or another..."

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 was one of the few students who knew how to use a debugger (which wasn't taught in the course). Most of the other students had a really hard time with the course because they were basically expected to get their programs right the first time.

So I'd say teach the students how to use a debugger from the beginning. Unless you intend the course to be one that "weeds out" any student who isn't 100% dedicated to earning a CS degree...

Anti-IDE snobbery...

[patio11]

... seems to me a lot like trying to teach your hardware guys circuit design without using VHDL, Xilinx, and the other automated tools that make this a heck of a lot easier. "Back in the day, I drew out all my circuits on an easel! If I wanted a multiplexor, I had to understand how the multiplexor worked and write it out directly in NAND gates rather than just picking it from a box of commonly used components! And I walked uphill both ways to school through the driving snow! Whippersnappers like you don't know how stupid you really are and how much your tools are a crutch!" Which is great, except the complexity of actual hardware design nowadays mandates the use of VHDL/Xilinx/etc and if you want to persue it professionally you will need to know how to work these. Software is similar -- even if you *could* do everything in Notepad and a command line there's no reason to do so when the guy in the next cubicle doing the same stuff in in an IDE produces better stuff quicker than you do.

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.

Re:Go for the IDE

[thelamecamel]

Yes, we hate said English teachers, but being forced to write things by hand often does produce a better assignment - you are forced to redraft (at least once). When you redraft by hand, you have to write every word again, which gives you time to think carefully about every individual sentence each time you write it out. If you use a Word Processor, then if you redraft at all, you're likely just to skim read what you've already written.

The same goes for copying down what's written on the board in maths lectures, compared to reading through the notes. One way forces you to take longer over each point, giving you time to completely digest what is happening rather than saying 'i understand that' and moving on.

Re:Go for the IDE

[Nutria]

I'm sure we all hate the English teacher who has us handwriting because word processors are a tool of Satan.

What planet are you from?

My teachers probably would have given an extra 5 points for papers that had been typed. That way, they wouldn't have to read boys' illegible chicken scratch.

We probably all think "But the word processor helps EVERYONE to write better, thus improving the writing capabilities of humanity as a whole!"

I'm pretty sure that write better is poor grammar, but don't hold me to it.

What the text editor does is allow you to easily rewrite what turns out to be poor phrases or malformed thoughts. Of course, you've got to give a rat's ass, and not be destroyed by IM-speak.

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.

ed, em, en, ex, vi (Was: Re:Which came first?)

[jamesc]

... I guess the guy who wrote the first IDE used vi, but what did the guy who wrote vi use? It boggles the mind.

That would be Bill Joy, originally. Back then (~1976), he probably used ex, which was an extended rewrite of en, itself an improvement on em by George Coulouris. Em was Editor for Mortals, since only immortals could use ed. I've used ed. The horror! The horror! 8^)

All the programs from ed to ex were line editors. Vi contained ex, but also was a screen editor using termcap.

(For details, see Bill Joy's greatest gift to man - the vi editor and Interview with Bill Joy.)

Re:ed, em, en, ex, vi (Was: Re:Which came first?)

[Eudial]

Which springs the question: What was used to write ed? (Or was ed created in an explosion of bytes at the dawn of time?)

Re:... Yes and no

[grahammm]

Yes but.. What you say about tools like calculators and using APL for matrix manipulation is true. However, the student should be taught the 'manual' way first. When I was taught maths in the '70s (before the days of calculators, simple 4 function calculators were becoming affordable at about the time I left school), we were taught trig and calculus from first principles. Only when we had learnt that were we told "You will probably never have to do that again, you use books of tables etc where someone else has done the hard part for you, but you need to understand how the 'everyday working methods' work".

With IDEs, the same applies. The student should be taught how to do things manually before being introduced to the tool which will do all the "behind the scenes" work for them.

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

[jsebrech]

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.

Re:A scary story related to this question

[pnewhook]

Wow that is scary. No wonder I can't find programmers that know how to do anything in an embedded environment without a button marked 'run'.

By the time I graduated 10 years ago, we had to (among other things):
- write a real time multi-tasking OS with a non trivial application for a Motorola 68K processor in C/asm
- write a compiler for a given language (their own unique language)
- write a real time multi-process application to control a PBX in C
- write a real time application to control a physical robot

None of these used an IDE, and nowhere was a language ever taught (except Prolog) - it was expected you learn the languages yourself as it was the application that was important to the class.

The complier course especially gave great insight as to what a compiler really does. The quality of my code improved immensely once I learned what the compiler really does with the code.

IDEs come and go. If you are teaching a language, then give them an environment that doesn't hide anything of the language from them. It could be an IDE if its minimal, or it could be just text. Better yet let them choose whatever they want, but give them problems that the IDE can't help them with.

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).

How I was taught

[Fjodor42]

Just to chime in with a case story.

At Aarhus University, Denmark, the introductory course is taught using BlueJay and the book "Objects First with Java", ISBN 0-13-124933-9. It is quite pedagogical, and thoroughly teaches the concepts of objects/classes, and BlueJay represents structures using UML. The next course, Programming 2, is then taught on the basis of using emacs, but with students being free to use vi(m), Eclipse or whatever they preferred. This is with the book "Object Oriented Design and Patterns", ISBN 0-471-74487-5, which I can also recommend. Worth noting is, that at AU, the semesters are divided into 2 quarters, so the introductory and the second course runs over just one semester. /Fjodor

Re:In related questions...

[OpenSourced]

What do you gain by typing in a complete method name of a library class and getting it slightly wrong and then hunting down the errors with api docs and compiler messages compared to the IDE telling you the difference or even helping you to get it right in the first place

Nothing. If you know what the IDE is doing. Similarly, you gain nothing by doing a multiplication by hand if you have a calculator ready and you know what you are doing. If you have never learnt to do the thing by hand, you introduce a factor of "magic" in the process. Like, you do this, you do this, and then something happens and you have the result. The teacher probably has explained what is the magic doing. But the likelyhood of you remembering is small. What's the use of remembering it if it's always done by magic?

I can see that in many programmers, both young and old. They program by some magic recipes, and the moment something fails, they don't know how the basic structure is (for example they don't really know about libraries and linking. They just know that when you need to access function X, you need to add Y to the code, and then an error can pop up in the magic linking process, and that means that you have done something wrong in your incantation to get X working, so you retrace your magic procedure to see where you angered the Gods by not following the prescribed ritual.

Also there are many that don't really know how the Internet works, they are at the same level with the user public. But they program Web apps! Only don't ask them if a feature is best done in server-side vs. client-side because you'll find the depth of their disinformation.

Answers vary depending on the situation...

[Vellmont]

I think any advanced programmer should learn a language with all the tools available to him/her. But it sounds like you're teaching beginning students who've only done a semester of VB or C++. I think at this stage a complex IDE will only get in the way.

A lot of people seem to be of the opinion that IDEs are somehow "soft" on students, and they won't learn anything with them. I think this is pure nonsense. It reminds me of the people who argue against letting kids who already know how to add, subtract, multiply and divide use calculators. (It's actually worse than this since an IDE doesn't actually program for you, while a calculator actually does do mathematical operations).

IDEs tend to be extremely complicated pieces of software, so students will end up using a lot of time learning the IDE. When to introduce them to everyone is a judgement call, but I'd still say for 2nd semester students it's more of a hinderance than a help. If you could somehow find a very limited scope IDE that only did things like finding syntax errors and didn't take more than a few minutes to learn, I'd say introduce that IDE right away, even in a first programming course. After a third or forth semester of programming it should actively encouraged to use a more complicated IDE.

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:... Yes and no

[zootm]

Definately. Although I don't agree with people who say you should be taught assembly language before normal programming (languages are a fairly full conceptual abstraction of machine code, learning it can be an impediment some of the time, other than perhaps languages with direct memory management, but even then I'm not sold on the idea), you should definately learn your languages first. If you learn the language, then the IDE, it eases your work, and it's easy to learn, because you understand why its features are helpful. If you start with an IDE, changing to another language, or even to another IDE, can be very difficult.

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:Me too!

[mqj]

Yeah, it was fixed in cvs!

Nah...

[Morosoph]

Cat is the way to go. As follows:

$> cat > hello.c
#include <stdio.h>

int main (void) {
        printf ("Hello World!\n");
        return 0; /* success */
}
^d
$> gcc hello.c
$> ./a.out

My Experience Teaching

[dcollins]

I also teach at a community college for the past 4 years. The students need a LOT of help (you'll be flabbergasted) -- enrollment is down 50% in the last few years all over the country, administrators tell me students are "scared" of programming, etc.

Here's what I do. Get the best book you can find and work lockstep with that book. Do the same in class as they'll be seeing in the book. They don't have the capacity to learn multiple environments and compare & contrast mentally.

For me, I fell in love with Lewis & Loftus "Java Software Solutions". It comes with a CD with all the code, SDK, and free jGRASP IDE (and very good supplemental materials). So that's what I use; students just install everything on the CD and they're good to go.

Having my materials all strongly synchronized is more important than any particular ideology to me. If the book emphasized command-line work I'd do that. (I do have a single handout describing command-line development which more advanced students might wish to pursue.)

Re:Go for the IDE

[Toshio]

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:

1. theory
   where I had to display the knowledge of axioms and theorems
2. practice
   where I had to display the knowledge of using the theory on short practical tasks
3. and Mathematica (Wolfram Research)
   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.

Hmmm...

[Morosoph]

You are supposed to be training them for the work place.

Not yet. If you do that from the beginning, they'll never learn fundementals.

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!

IDE?

[Chris Mattern]

Nope, SCSI all the way!

Chris Mattern

please don't!

[Lord Ender]

By today's standards, Emacs is the UI from hell. My shool used it to teach CS, and many otherwise smart people were severly hampered by it. They spent more time messing with the editor than with their code! And you don't want a person's first experience with unix to be one as frustrating as emacs.

The focus should be 100% on the code. The editor should be completely transparent to the student.

Eclipse

[Stalus]

I was a TA a couple of years ago for the intro java course at a Big 10 university, and I'd recommend using Eclipse - at least for the Java part. Honestly, you can show them the non-IDE approach in a day, and cover your bases. The only thing of value you're teaching them there is that javac makes byte code, and how to run the virtual machine/set up a class path. For students with a year under their belt, it shouldn't take them too long to figure this out.

We used to use a poor IDE, but a number of the grad students convinced the university to switch to Eclipse. There are a lot of benefits, but here's two:

First, code completion, and tool-tip documentation helps the students learn the API. Students with C++ experience will be trying to overcome the fact that everything's a reference, default virtual methods, garbage collection, and basic java syntax. Forcing them to memorize the API and its associated documentation is a waste of time when good tools exist to feed them this information as they need it. It also does some import statements for you, which is so very nice.

Second, error detection and suggestions teach the students as they go. If they type up a bunch of code and compile it, they'll get some error on the first thing they worked on, and their head will be on something else, so it just confuses them. Eclipse highlights syntax errors as you type, so you catch and correct these errors while your thought process is still in the right context. In addition, Eclipse will suggest corrections for common errors, typos, etc. Error messages may seem intuitive to the experienced programmer, but to a novice, it's just greek. I think I spent most of my lab time trying to convey to students what the error messages really meant, and how they could use them to fix their code.

Bottom line is, learning is a process where you learn one thing at a time, and feedback at any step of the process is good. By using a good IDE, you are able to focus on more general concepts, which are transferable to other languages. Otherwise, they just learn the API and what the error messages mean, and lose a lot of valuable time.

Just my two cents.

trick question... :)

[grikdog]

This reminds me of a job interview I had in which the question was broached whether I wrote Quark XTensions from scratch, or modified existing code? It was late in the afternoon, so I scratched my head and jumped on the wrong side of the rail. (The answer by the way is, "Uhh, gosh, I CAN write from scratch, but I ACTUALLY modify existing code. It's faster.")

In the real world, nobody in their right minds works without an IDE. So teach it that way.

IDE lets you focus on programming

[Junks Jerzey]

All this anti-IDE angst, so let me give the opposite view. Beginning students should be focused on *programming.* A good IDE makes some key things standard and invisible: jumping to errors, debugging, etc. Then the students can just worry about programming, and not vi configuration problems and make files and so on.

Using an IDE in school is nothing new. Back in the late 80s most of the college programming courses I took used Pascal, and Turbo Pascal 4 and 5, with integrated editors and compilers, were godsends. The alternative was to use a command line compiler on a VAX, which was horrible in comparison.

Re:... Yes and no

[Planesdragon]

They shouldn't even get a GUI. The first couple of semesters should be taught on Linux machines without X installed. I've seen nothing to indicate that a GUI does anything other than get in the way of understanding what's going on behind the scenes.

A GUI -- with a good IDE -- does one thing that tossing the kids at a command line won't do. It makes it easy to "get into" programming. At the least, the FIRST class should be taught with an IDE. Maybe even using Visual Basic or OOo's BASIC. Once they go from drooling non-programmers, and have both a little confidence and a little knowledge, slap them into full-bore programming.

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

A good programmer is a lazy programmer

[solidcomputing]

One lesson on CLI based compiling is all that's needed. Developers made IDE's for developers to speed up development. Using CLI should only be used to make minor changes over ssh; suggesting otherwise would be like saying "why don't you teach how to use punch-cards". Press the forward button, teach Netbeans and code-completion, not CLI, vi, or notepad. Spend the saved time teaching UML and project-management skills and how to find existing projects on sourceforge, or even how to start one. Anything to reduce coding time. The average human lifespan is only about 80 years, and by the time you get up to 70 years old you probably won't remember enough syntax to code anything. Coding is something you do only when necessary. A good programmer is a lazy programmer with good business sense. btw, I've never used punch-cards, have you? Educational institutions are always slow to catch up. It's the same reason why students still learn how to build compilers and assemblers. They graduate thinking that they have to write a new programming language. Remember, human lifespan is only 80 years, try to fit in some leisure time in there.

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.

Go to the accounting department...

[clambake]

As the accouting professor if he teaches people accounting first on paper or using Excel. Whatever he answers is what you should do as well.

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.

FOR THE LOVE OF ALL THAT IS GOOD IN THE WORLD...

[fzammett]

...TEACH THEM WITHOUT AN IDE!!!

I cannot tell you how many people I deal with all the time that simply cannot function without an IDE. An IDE is a tool, not a crutch, and I see too many people using it a a crutch. Until you are 100% sure they know the underlying concepts, DO NOT let them use a tool that might save them a few seconds of actual thought. I can't stress is enough. I've seen the results of people that can't perform without the computer thinking for them.

The business world will eventually learn that hacks throwing together craplets costs them far more time and money then a few talented developers doing it right the first time. Or they will continue to throw money at the problem, expecting that just getting 30 warm bodies that know how to press the right buttons in the right IDE will be a good strategic plan. Chances are the truth won't be realized until they go out of business.

Also, I should point out that I hear so many stories on a nearly daily basis on how the IDE didn't do what it was supposed to and someone spent four hours figuring out why it was munging a classpath, or not generating the XML config files for framework X properly, or some such mess. They spend more time fighting the tool than they do getting work done. It's a joke! How exactly is that IDE making them more efficient?!?

I don't mind if people want to use an IDE. I personally don't, and I frankly work more efficiently than a great deal of people I know who swear by IDEs (I'm a bit of an extreme case though... after 20+ years of programming, my technique is pretty refined). But if your going to use an IDE, you damned well better know what's going on underneath. If you don't then you have no business developing in the first place.

Related to this is my lamentations about people not knowing low-level programming any more... hell, even I haven't written real code in Assembly in a few years, but I *did* for a while, and I understand all the basic concepts... just being able to "think like a computer", which you'll never learn using tools that hide the details from you, is a lost skill IMO, and is the reason so many crap developers are floating around these days. It's all about thought process, not about what real skills you have. Anyone can memorize this algorithm or that domain model, but the people that can derive them themselves (or something roughly equivalent anyway) are the ones that are worth something. If you aren't "in sync" with the computer, at both a low and high level, your not an especially good developer IMO. IDEs make it easier for those that don't understand to *appear* to be in sync, but they really aren't.

Eh, whatever. The "best" development environment is an age old debate. If you have the basic skills, its a moot point: use whatever your most comfortable with and can be most efficient with. For some it's Eclipse with all sorts of plugins, for some it's vi and a command prompt. If your learning though, and if your teaching, do yourself and your students a favor and don't allow them to become crap developers who can only push buttons to get the desired output like trained monkeys. Force them to think, force them to become as intimate as possible with the machine (which is already difficult in Java, but still), and only *after* you are sure they are, *then* introduce them to the tools that will theoretically make them more efficient.

It's just my opinion, but it happens to be right ;)

Both

[Etriaph]

First of all, you should teach formal logic on a blackboard. I wouldn't let someone touch a computer unless they knew the difference between a scalar and a list.

Secondly, they should learn how to implement this knowledge in the most simple language possible. BASIC, Pascal, etc. Don't confuse them with an advanced tool when it's the code that matters at this point.

After that, keep raising the bar and exposing them to more and more of the language, then introduce the IDE. How code translates to the machine, to the project, to the enterprise is irrelevant if they would-be software developer doesn't understand a control statement. Keep the focus on the code before you introduce a way to make it easier. The learning curve is steep enough for some.

That's my two cents.

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.

To IDE or not to IDE...

[BytePusher]

I suggest not using an IDE, because in the end you will be freeing your students from being dependent on a particular piece of software. Another benefit is that they will natually begin to understand what actually occurs during linking. Granted, you don't really link with python, but maybe python wouldn't be the best first language. I recall not really knowing at first that Microsoft Visual Studio wasn't compiling my software. I was amazed to find out I could do it by hand from the command prompt. I feel that was the opposite of how it should have been.
          That said, for large projects, I use an IDE every day. Every now and then I'll transfer a project over to a different IDE just to see if I like it better. Sometimes I need to dig in and fix a makefile.am, but since I know the nuts and bolts I'm free to do so.
          I'd recommend you teach them to use the best tool for the job. At first, for single file projects, an IDE is a bulldozer in a flower garden. Forcing someone to compile every file by hand and then link by hand would be like like bringing a spade into a construction yard. Neither fit quite right, but might eventually get the job done. So if it were me... I'd give them tools as they need them. Make them compile and link a three file project and say, "hey look here's something that will make it a little easier." Then students could use the tools as seemed best to them.

Yes, please enhance my job security...

[nixkuroi]

I say teach them with the IDE, so when they get in the real world and need to hack a way around a design limitation or integrate with a data provider that they can't bind a control to, they have to call someone like me who does. :) document.getElementById("indeed").parentNode.remov eChild(document.getElementById("indeed"));

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.