Slashdot Mirror
Should Students Be Taught With or Without an IDE?
bblazer asks: "Beginning this next school year, there is a strong possibility I will be teaching an intro to Java and an intro to Python course at the local community college. I was wondering what the prevailing wisdom is when it comes to teaching languages - should students be taught with or without an IDE? I am a bit old school and wouldn't mind having them all use vi or emacs, but using a good IDE does have some advantages as well. I should note that the students I will be teaching will have had at least 1 semester of programming in VB or C++." Even though there is limited time in a semester, could a curriculum be constructed to accommodate both methods?
but what is an IDE? In the case you are reffering to?
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].
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.
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.
Go for the IDE, its all a tool used to get work done. You don't want to spend time learning little technicalities of compiling something when you could actually be programming usefull code.
Go with an IDE. They could use the experience with easy debugging.
Besides, even if you push vi/emacs and a commandline compiler, a lot of students will most likely use an IDE anyway. At least that is what I saw when I was a student.
I can't speak from experience for emacs, but I know vi has the ability to do syntax highlighting. While most IDEs do statement completion for you(along with listing parameters and options), I always found having a language reference next to me to be more useful as when I was in need of knowing the function I needed, I also needed to know it's parameters and what they did anyways. I'd say vi would be great to learn the language if they don't already have to learn vi. If a majority of the students don't already know how to use vi, using an IDE would probably allow the students to get more out of the course.
Humans are slow, innaccurate, and brilliant; computers are fast, acurrate, and dumb; together they are unbeatable
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.
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.
No, I will not work for your startup
I generally prefer without. My intro CS course (in Java) five years ago was taught using emacs (which I actually didn't like at the time), and part of the beginning of the course was graded on knowing emacs shortcuts. A later course that I was a TA for used BlueJay, and again grading was done dependent on using that IDE.
I am more a fan of letting students choose their own environment. I've been using UltraEdit for a long long time, and I'm very happy with it. My suggestion would be to give students a list of good editor options, but not require them to use any single one. Maybe a later lesson could focus on the debugging potential of one IDE or another (I hate to say it, but Microsoft has some great debuggers). My experience, though, is that the main issue for students is what they're writing, not how they write it.
Bravery is not a function of firepower.
~J.C. Denton (Deus Ex)
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.
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.
My experience in the as an long time employed developer would tell me that you should use an IDE. In the last ten years I have not held a job where anyone in the staff, under the age of 40, used anything but a well known IDE. This is even more true regarding Java, and I can't really comment on python, havening never used it profesionally. In general I have always felt that school should be educating people towards practical skills, and even the old school developers (I'm an old school assembler myself) use IDEs now days.
Part of practical language experience [since you're not actually teaching programming] is learning to use a/the common IDE.
Why have one at all? Unless your class is on the specific IDE or "Software Development Techiniques", why chain them to a specific technology? Let your students figure out how to run the damn editor. If it wasn't so tedious, I'd say have your students turn in assignments on paper. You are teaching programming, not a program, no matter how community college you are. Give your students a chance to figure something out for themselves and they will become smarter.
Did you ever notice that *nix doesn't even cover Linux?
For Java, I've heard some good things about Eclipse. The learning curve may be a little steep. Sun is supposed to have a good (and free) IDE for java also.
In Python, I like Idle. It comes with Python, and while sort of basic, it does all I have needed.
Go with an IDE, even if it is a free one.
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.
For Python, just use IDLE. You don't really need much more for python...
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 don't have any significant experience with Java, but I have done a fair bit of work in Python. When in my freshman year in college, I wrote several physics simulators that used the Visual module (also known as Visual Python or VPython) and I can safely say that the IDLE IDE was a big part of my being able to pick up the language quickly.
So for Python, definitely use IDLE in some form or another.
Those who choose convenience over inconvenience deserve it
The sooner you fall behind, the more time you have to catch up.
If they are just going to be coding scripts or simple small programs, a normal editor like Vi/Emacs might work quite well, or a similar text editor. but if it may be on a slightly larger scale, an IDE might be better, since it allows greater organization.
In undeveloped countries, the consumer controls the market. In capitalist America, the market controls you.
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.
For simplicity sake, you can introduce them to an IDE on day one, but it's important to cover what is happening.
Case in point, I had a friend who is taking some programming classes and was absolutely baffled on compiling from multiple files. Their instructor apparently likes them to "dig" in and then teach from what I gather. It's a simple matter in the end, to create some header files and segment logical code and make sure they are included under that project hierarchy. However, certain compiler flags and inclusions are essentially hidden from their point of view. I don't know if they planned on covering that, but I pointed them out some resources and gave my fairly rough explanation. (It was already written else where so I didn't feel much need to regouge the wheel)
So while I don't think it's a bad idea to start someone off on a good IDE, I don't think it's entirely a bad idea either to explain whats happening or even show off how things work on the command line.
It's along the same lines of how a past instructor taught VB. (Yes, had one class of VB, but we mostly used it for the GUI side and wrote our dll's in C++) As he taught the programming, even with some dig in approaches, he explained a great deal of things going on behind the scenes. I can say the extra understanding helped me to be a better VB programmer because understanding how things worked helped me optimize my code. (Extra points as well since our end sememester bonus points/work/competition included several pieces of code to optimize for speed. Slammed 3 of the 4 for best speed improvements and I didn't even need it for the A... I'm a bastard.)
"You should always go to other people's funerals; otherwise, they won't come to yours." -- Yogi Berra
A big IDE like Eclipse would not be a great idea, but vi and emacs would also get in the way of teaching the students about the language. I'd suggest something simple like jedit.
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
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.
The IDE is a convenient way to combine tools. The important thing is that students understand how to use a debugger to inspect a program as it is running, and a profiler so that they gain an understanding of what is and isnt important to performance. Most good IDEs make debugging easier and more powerful. Some have good profiling tools, too.
But then, this depends on the curriculum actially taking advantage of tools like debuggers and profilers. But, with Eclipse, Netbeans, and some versions of Visual Studio available at no cost, there is no excuse to deprive students of the easiest environment in which to use these tools. The command line adds nothing to the learning experience.
I wrote parts of this stuff
I would consider a powerful IDE like Eclipse as a important teaching aid in itself, almost an automated tutor.
I have just completed an MSc course myself which looked at computer aided training. The conclusion was that the best computer aided training is one that interacts with the student, identifies mistakes and suggests possible solutions, much like a live tutor does.
My Eclipse installation is as close to that ideal as I have come across; it highlights missing punctuation, identifies missing import statements and points out many errors as I make them, and generally directs me to write correct code. If you pay attention to what your IDE is telling you, you can learn a lot, and quickly. I certainly considered the learning experience more fulfilling and more enjoyable than wrestling with obscure compiler errors.Perhaps an IDE shopuld be considered as a teaching aid, a better question is what Eclipse plugins would Slashdot readers recommend to build the perfect learning environment.
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.
Beauty is just a light switch away.
The man says he's teaching Intro to Java and Intro to Python. He does not say that he's teaching "Programming 101". These are courses mainly on basic language syntax, and how to write simple programs in each language - why not use an IDE to help out?
The type of person taking an intro course with a title like that is not trying to learn to program in general terms, they're trying to learn the basics of a language, and an IDE can help with that.
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.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
BTW, given the way the original question was asked, I would have just answered "yes".
I taught college level math (trig through intro to calculus) back in the '80s and the same debate raged with regard to using calculators. If I was teaching arithemtic, I would argue against using calculators since the whole idea is the class is supposed to be about learning simple skills like add, subtract, multiply and divide. If I'm teaching a higher level subject like trig or calculus, I'd say using calculators is great because it allows the students to concentrate on the concepts and not get bogged down in the arithmetic. Hell, when I was working on my MS I used an IBM 5100 running APL to do a bunch of the matrix manipulations for my abstract algebra class and the prof thought it was great since I wasn't spending hours row reducing matrices to get eigenvectors and eigenvalues.
I would argue that the same principle applies here. Higher level classes should encourage the students to use an IDE and higher level languages since the idea is to teach them concepts like data structures, complexity theory, numerical algorithms, etc. Introductory classes really benefit from having the students flail at things like compiler errors and trivial logic errors that a good IDE flags so they understand how little a computer can do until someone programs it. In between, the students need to be exposed to an IDE in a way that makes the transition itself a learning experience and ties in with software engineering, tools and the whole mess that Fred Brooks charaterized as accident vs. essence.
I'd also like to see a class that has students solve a problem using a programming language that's appropriate for the task and one that isn't (e.g., COBOL for a CGI problem) just so they also get some understanding of how using the right tool for the job makes a difference and the problem domain for a given tool is limited. This is probably beyond the scope of the original question.
Cheers,
Dave
They that can give up essential liberty to obtain a little temporary safety deserve neither safety nor liberty.
Ben
I think students definitely need to be introduced to coding without an IDE. I have a good friend who graduated a couple of semesters before me. I sent him some code to look at that I had been working on, and he had absolutely no idea how to compile it without using an IDE (and it wasn't some horribly complex application in 12 different languages or anything, it was around 4 .java files, and had no weird dependencies or anything). This was someone who graduated with a degree in CIS and already had a degree in CET, had been using Linux for years, and he still didn't really get what was going on with compilation.
That said, I think a short introduction early on should be enough. For beginning students a good IDE can help to re-enforce the learning. Syntax highlighting can help them to remember keywords, and auto-intention and braces can help keep their code clean so they don't get too frustrated early on.
Code completion is a bit of a double-edged sword. It can help students to remember the names of functions, etc. but it could be bad if they come to rely on it too much early on.
I also agree with some of the other posters who have said that vi and emacs might have too steep of a learning curve. If you are on Windows, then Textpad is a fairly nice program that is sort of half-way between a text editor and a fully featured IDE.
I've been trying to put materials together recently to start teaching a volunteer community education class on Java programming, and considering everything I've mentioned above, my plan is to give an introduction to compiling from the command line, and have student practice building demo programs from the command line, and then introduce a couple of IDEs (I plan to demo Eclipse, Netbeans, and X Code). From there on I'll probably tell students to play around with each and then stick with their favorite way of developing, while giving demos in Eclipse, simply because it's the IDE I prefer (though I run most things from the command line outside of Eclipse, and end up using Eclipse as a glorified text editor, mainly because my notebook is underpowered enough that the speed difference justifies the tiny amount of extra effort).
Famous Last Words: "hmm...wikipedia says it's edible"
I like vi(vim) and while it does have syntax high-lighting it also has a learning curve to it. The goal here is to teach the students a language, not an editor. If you don't want to go for a full IDE I'd suggest using JEdit, it's free and has syntax highlighting for just about every language. It'll also help match up curly braces but that's about it without any plugins.
The thing I like about using JEdit instead of an IDE is that it does NOT do auto-completion by default. It makes the students memorize Java syntax a little better but they'll also have issues running the command line compiler.
Beginning Java students will have trouble understanding the error message of the command-line compiler. With a little introduction an IDE will provide a much less frustrating experience for students. Another positive of an IDE is a standardized project structure which will make your life easier when students turn in work.
I've trained several college instructors and had this discussion a couple of times and they usually end up using JEdit, Eclipse, or Netbeans. Myself, I lean a little bit towards JEdit but I typically get to hover over my students and help them with any problems.
My Hello World is 512 bytes. But it's also a valid Fat12 boot sector, Fat12 file reader, and Pmode routine.
I agree with what has been proposed previously, teaching both. However, I think students should be taught without an IDE for most of the time. I can remember being in a computer lab and a sophmore asking me how to compile some program. He had no idea that you could compile a program without his pretty IDE. All he knew was that he wrote some code and pressed a magic button and presto... his program was compiled. He had no idea what to do if something went wrong. Teaching without an IDE will take away some of the mystery and give students a better grasp of what is going on.
If you teach it without an IDE you will also make a better cross platform programmer. *nix OSes typically use Makefiles for most projects. Typically with makefiles you need to know what options to give your compiler (ie. know something other than push a button on the IDE) for the program to correctly compile.
There is also no common interface to IDEs (although most have similar features), so what you teach with in an IDE the class could become "This how to use this particular IDE tool". If you teach the stuff behind the IDE, in my opinion, the programmer will be able to handle just about any IDE because he knows whats going on behind the scenes. Just like when you teach programming, you teach Data Structures, Control Structures, Algorithms, etc., rather than simply teaching how to program in a particular language because if you know these fundamentals then you will be able to use any programming language, because its simply a matter of syntax. If you teach the fundamentals of the compiler, different IDE s will simply a matter interface.
Thats just my 2 cents.
Because it allows the kids to play with methods/objects independant of the rest of the program. Great for debugging when you're learning (and just plain learning).
It's somewhat of a lightweight, no frills IDE at that. It also does a bit of the UML stuff.
After playing with it a while, I wish I had something like it for C++ debugging. Makes testing a whole lot easier.
Clones are people two.
Im a bit old school myself. 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. The same people taught on an IDE would have no idea how to compile by command, now this is not a problem if they always use an IDE but when you get into optimization and such it makes things easier. Now many people here have mentioned that it will help them get away from making simple mistakes, well you want them to make these mistakes. You learn from your mistakes, this way you dont make these simple mistakes and will help them get into the habit of cleaner, better written code.
After they have learned the basics and are comfortable with the mechanics of writing/compiling code, introduce them to an IDE (Eclipse and NetBeans are both free, as id Sun's Java Creator Studio) since that's the environment they will likely use in the real world.
The contest for ages has been to rescue liberty from the grasp of executive power. -- Daniel Webster
There is a point in coding where your eyes just glaze over and you cannot quite fathom where the hell the tiny little mistake is because everything reads right.
Your head eventually clicks: oh, it's a damned semi-colon needed right there! Grrrr.
And then you resume life for a few hours.
For these reasons, it's better to let folks find their own groove.
I scream. You scream. I assume that means we're both acquainted with the problem. We proceed.
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.
I'll subscribe to Slashdot when I see a month without a dupe, a typo, or an article the "editors" didn't read.
The question is whether you want to teach people to program, or teach them to use an IDE.
On the left hand, the ide simplifies some the 'magic' to get the beginner going and writing code as quickly as possible. On the right hand, the ide does so much for you that you might not learn the underlying structures.
I am right handed on this one. While IDE's are an excellent tool, without knowing how a program is actually assembled (both literally and figurativley speaking,) then what the IDE is doing is just magic as far as the student can understand. However with that knowledge, then the IDE becomes a powerful tool to be used and abused to maximum gain.
I worry about the seperation between learning to program, and learning how to use one vendor's non-portable tools. Learning to program is more about problem solving, symbolic logic, and learning how to read the manual -- generally being flexible. In the real world, most of the time you will be given a workstation with some IDE or related system already in place, and told to use it. Without the basic understanding, you are screwed. Of course, after a few years and promotions if you are a good little code monkey, you may get to help choose the new tools, but most places I have ever been have so much time and code invested in legacy systems that the only change vendors when they go out of business -- and then, the places I work ususally use the last released version of the tool untill it will no longer compile executables for the target systems.
Besides, if you learn how to do it purely in text mode, then you have the moral authority to talk about the good old days and weigh in on editor wars. And, you would be suprised what a breath of fresh air finding someone installed an old version of VI (not even VIM, true VI) is when you sudenly get handed a software maintenance task on a VMS-Vaxen, and you are not old enough to have used them in kindergarten!
More Caffeine. NOW
This comes up a lot on the Sun's Java Fourms and the response I always like to give that when learning Java you should avoid using a full-blown IDE until you can compile and run applications from the command line and use the online javadocs, otherwise you learn a tool, i.e. Eclipse, NetBeans, Intellij, etc., rather than the language and/or "how to program". Saying all that, I do think it's ok if students want to use an editor like JEdit or TextMate, that provides syntax highlighting and code formatting.
If the primary objective is to introduce the specific languages, the IDE will be a useful tool; however, I'd recommend that they be made to work in more than one IDE (or with just a text editor for some assignments, if economics preclude multiple IDEs), since it's dangerously easy to develop knowlege of and over-reliance on a particular IDE, rather than knowlege of and skill with the language desired.
//Information does not want to be free; it wants to breed.
When I was your age, we didn't have no fancy IDEs. We used Coding Forms. And we LIKED it.
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.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
They must know the commands, and the switches, but they should also be able to use an IDE to automate the task of retyping the same commands over and over and over and over, Sorry.
For Students, I recommend Eclipse. Start plain and teach the commands to do each task and then teach it to the IDE.
*Disclaimer, I use Kdevelop but drop to command line to compile and strip and tar and copy. This is usually an Up arrow keystroke. Maximized Productivity.
OSGGFG - Open Source Gamers Guide to Free Games
Yeah, it's basically impossible to go 'old school' with Java, being such a high level language.
...just in case they are ever stranded on a desert island without an IDE. *Then* what would they do?? Huh?? You little punks!!
Last summer when I took intro to programming we did both. We started off using DrJava and then eventually learned to use vi. It was better at first to use the program because as an introductory course, it was incredibly frustrating to try to make a very basic program run when you hadn't yet learned the little things. Using DrJava made it easier and better to get a sence of achivement when something actually worked. Plus it gave us a bit of a sandbox to mess around in without having to compile every single time when we just wanted to see what would happen if we changed one little bit of the code. Once we got the basics down, then we gradually stopped using DrJava.
http://www.popularculturegaming.com -- my blog about the culture of videogame players
Offer them an IDE (there aren't many good ones for Python, and Eclipse is a piece of steaming crap) and offer them to use an IDE of their choice. Offer them to use any text editor they like and show them how to use the command line compiler interfaces (quickly, they can read, they aren't stupid).
If you force them the ones who get slightly annoyed will learn to passionately hate it (thus is the origins for my hatred of Eclipse). Interestingly enough, I was also forced to use Visual Studio at one point; but it's actually a well written piece of software that works. Eclipse loves to do two things:
1.) Suck a hundred times more resources than makes sense.
2.) Crash when I'm doing something important.
So why erect any more barriers than you have to? If students associate vi or emacs with programming, they'll end up hating programming. Forget "old school". It's the 21st century, and IDEs make programming fun.
I think you should teach them three things:
1) how to compile using a shell script. this is probably only appropriate for the first "hello world" assignment with one class. this will show them how to use java and javac directly.
2) how to use ANT. this would be a more complex program with several classes. this will teach them how to compile a lot of open source projects.
3) how to use eclipse. probably you would have some kind of GUI widgets. maybe have them make a calculator.
Actually, Fujitsu was promoting COBOL, more specifically, a few of their extensions, as a CGI type language back in the late 90s. I picked a book on COBOL back in the day, course I never programed even hello world, because COBOL has a syntax only its mother could love.
Marxism is the opiate of dumbasses
I don't consider this a simple matter of using an IDE or not...
Most modern IDEs include "wizards" that write 90% of the framework code of a given project. The programmer just needs to plug in a few callbacks and call it a day.
Now, although I personally think I can write better framework code, I don't have a problem with someone using a wizard, once they already understand exactly what it does for them.
Put bluntly - Someone taking a college-level programming course should damned well know how to write, from scratch and with nothing more helpful than emacs/vi/notepad, a program that will successfully compile.
Even in the Windows world, and even just a single dialog-box with a custom windowproc version of the standard "hello world" program, a coder should have the ability to write that from scratch.
If they can't cut it with that - Better they learn they can't actually code in the second semester than the eighth.
Specify use of an open source compiler, and leave the editor to the students. Demo simple emacs and recommend vi too. Set up ssh to individual student accounts on a linux box at the college, and collect homework by having sourcecode dropped on your linux box. Then just teach the language.
From personal experience, this works well -- students start thinking.
I was first taught to program C++ back in high school with Visual Studio, and then introduced to vi in undergrad for Java, C, and everything else. I like having an IDE available to work with Java applications and whatnot, and I like using emacs or something equivalent for writing in perl and C. Introduce your students to both and let them pick what they like, its really a matter of preference after all. Just make sure that if they are using an IDE, they don't become reliant on wizards to write their code.
The problem is to clearly separate the language, the compiler and the IDE in the students' mind. So, either show them how it works without IDE, or show two different IDEs.
Real java projects generally use ant as the main build method, show them how to set up aq project with ant for the first half of the class.. Show them the command line tools and emacs of vi, Then let them take that same project and run it in eclipse... Programming on a modern IDE is a completly different experience then emacs... But both are valuable...
SATA or SCSI drives should easily handle their needs better anyway.
"Waste not one watt!" - CZ
Learn how to write a make file, learn how to configure and use emacs and learn how to use the commandline debugger.
teach first who-to program only after it teach who-to use a good ide, theres is no ide that kick ass a good programer,becouse ide don't make programs they just draw the app and have a bunch of wizards that make code actions for it, I can program a DB app using jb*ilder whitout type 2 lines of code,but if I have to make something the iDe don't do, only g**gle can help me :D
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.
Let them use any tool that allows them to compile the code properly. Choose one or two tool sets (perhaps one IDE tool set and one non-IDE one) to recommend, and provide instructions for those two. Make it clear that although they can use anything they want, you can't guarantee that you can help them with questions unless they are using one of the recommended ones. Explain the advantages and disadvantages of both so students can make an informed decision.
Being flexible has the advantage that students will learn to make choices that affect their ability to get things done. They can judge based on their experiences and their classmates' experiences whether they've made the best choice or not. If they've never used anything but an IDE and they want to learn about the command line, they can. If they don't want to or aren't at the level where they're ready, they don't have to. But those who are ready and who are interested can learn more of the guts of the compilation process. Also, even if most students don't choose the command line, the fact that some students do choose it (hopefully) might create awareness that it's an option. The act of thinking about the choices educates them no matter which they pick.
Basically, unless I understand the purpose of the course wrong, learning about the compilation process isn't one of the core goals. Some people won't be ready for that and it will only frustrate them for little gain if any (it might be a net loss if the frustration prevents them from learning everything else), so making it optional relieves that problem but allows those who want to learn something extra to learn it.
(For what it's worth, I originally learned on an IDE: it was Turbo Pascal 3.0. Worked well. I learned to use vi and cc (no, not gcc, yet) soon enough.)
What do the people who program the IDEs use? I guess the guy who wrote the first IDE used vi, but what did the guy who wrote vi use? It boggles the mind.
When I was in college is didn't matter if you used an IDE or not. What mattered was when you took a test, in front of a piece of paper, you knew how to code.
When we were tested, we didn't do it in front of a computer. You had to hand write the code. It wasn't type something, compile, run, fix mistakes, repeat. It was, get it right the first time else get reduction for each mistake.
If if you wanted to use an IDE, you could, however if you couldn't code on a piece of paper, you failed.
Comment removed based on user account deletion
The current minimum level of tech is a fixed-width font (effectively) unlimited line length editor such as gedit, kwrite or notepad.
This is a reasonable level for an introductory programming student to write their code in. It offers the user the opportunity to validate grammar, speling and style.
A more advanced student will humor you and tell you he used the prescribed program to edit the text.
I hate to confess this, but the days spent looking for those missing commas, close parens, close braces and semicolons was in hindsight time well spent.
vi is over doing it. No modern programmer would use such an antiquated editor.
:q!
Help stamp out iliturcy.
Long answer: the goal of an intro course can be one (or both) of two things:
Neither one of these goals is served by teaching the details of what goes on under the hood in an IDE. That can come later, for students in category 2.
--
Carnage Blender : Meet interesting people. Kill them.
At University of New Hampshire, most people begins with vi and emacs (or even pico, but it was not recomended) on the University Linux systems. As they get into classes which require more programming many people typically "discover" IDEs on their own. Additionally, in some courses a grad student TA will give an introductory lecture about an IDE like Eclipse. It works pretty well. I began myself with vim, then used Eclipse for Software Engineering class taught in Java. I switched back to vim and make for my last class and now I am using Visual Studio at work :)
isomerica.net | Foonetic IRC
Every serious programming student should learn at least 2 IDEs from different vendors, at least 2 different command-prompt-styles from different vendors (e.g. DOS and *n*x), and at least two different text editors, at least one of which should be nearly-bare-bones (open, save, backspace, insert, and cursor-movement or goto-line-number/character-position). If such a bare-bones editor isn't readily available, they should know how to use at least one editor as if it were a bare-bones editor. Doing so gives them a better understanding of what goes on in the compile/run/unit-test cycle. It also gives them some insight into what happens in the "build process" of a team project. It's the same reason students should learn to multiply in their head before they learn to use calculators.
Now, over the course of a student's degree, he may spend 90% of the time on a single IDE. The goal is to make sure he CAN edit, save, compile, link, and run hello_world.{language} using two different IDEs, without IDEs using a plain and not-so-plain text editor using two different command interpreters in two different run-time environments.
If your students are getting their "taste of doing it the hard way" in another class, no need for you to torture them again. Likewise, if your students are in a short program of study, something less than an associates degree, it may not be worth the bother either.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
BTW, given the way the original question was asked, I would have just answered "yes".
Q: Should students be taught with or without an IDE?
A: Yes.
-:sigma.SB
WARN
THERE IS ANOTHER SYSTEM
YES! Vi is definitely a good first assignment. Learning to edit efficiently is just another aspect of programming. In fact, many professionals suffer from an inability to edit efficiently. Doomed to waste years of their lives using the mouse to slowly click about. Just be sure to use the Seven habits of effective text editing as at least an available resource.
On undertaking a particularly large assignment in college I took it upon myself to learn vi in the process. I can definitely say it was something I should have done a long time before. Pico/Nano, notepad, edit, text edit, gedit. All of those inferior editors should be uninstalled from the labs or students will never learn to do better. I can't believe how stupid I was for ever using pico.
Browsing through the other comments, it looks like everyone's assuming you're going to be teaching 20 year old kids who are expected to delve deeper into programming. Is that the case? To me, intro to programming at a community college could just as easily mean teaching someone who's taking this class alone without anything further. The first question I'd ask is who you're teaching. If you're trying to teach my grandma to add some sparkle to her webpage or write some Excel macros, go with an IDE or you'll make her cry. If it's someone who's going to take a class or two & wants to know a little bit for improvements at a non-programming centered job (like me), go with an IDE. If it's someone you expect to spend a lifetime programming, start with the basics.
"Once in Hawaii I had sex with a 102 year old male turtle. It is difficult to argue that it was consensual." - Steve Ma
If we're talking a long term student taking a computer sci course, no ide. At most, ide agnostic. If you're teaching a community college class where students are taking a one-off course to get up to speed on a language or enhance their career, you're job is to give them the best tools and advice. Its about the students, not the teacher or the language.
IMO, a good IDE helps teach the language. I learned Java 100 times faster than I've learned any of the myriad other languages because Eclipse has a fabulous IDE for Java. I already knew programming constructs in general, and the Eclipse Java IDE led me through using those skills in a new language. Now I can dump the IDE and use joe or ultraedit or (FSM forbid, notepad or vi) and do fine.
The problem with quotes on the internet, is that nobody bothers to check their veracity. -- Abraham Lincoln
The upper level CS classes (300+) at my school are all taught with no IDE restrictions and we turn in code via a svn repository. I'd say that's the way to do it, that way people can use what they are comfortable with. If they don't know where to start, have them use vi or emacs, that way they can learn the skills early on.
All of you make the division seem magical. Care to clarify the difference? Remember any technology sufficiently advanced is indistinguishable from magic.
- An introduction to java course should not only teach about the language, but how to use the default tools (java, javac, javadoc, javap...) as well. Remember that java is more than just a language it is a runtime concept (VM) as well. I also suggest that you show your students the output of "javap -c" for hello world.
- Teaching without an IDE is keeping it simple. Students aren't stuck on how to try and use the IDE and are focused on learning the concepts that you want to teach them.
- I've found that some people coming out of college today don't really know what's going on behind the scenes because they've been allowed to use an IDE and not forced to use the command line. Using the command line forces students to understand what is going on behind the scenes.
- Sometimes you can't use an IDE in real life. I've actually had this problem at work in a couple situations. One - after IT installed an upgrade to our IDE, the IDE had several problems, basically making it impossible to edit or debug code. Since I didn't rely on the IDE, I had no problems completing my work. Two - (well with C++ apps) we would deploy with all debug information removed, to a machine that did not have an IDE or debugger installed, so we only could use logging and other runtime tools for debugging anything that we couldn't reproduce under development conditions. Third time - I decide to do some work while visiting my parents and bring my laptop with me. Unfortunately, it just doesn't have the RAM to support Eclipse. I had no problem dropping that and using ant/vim/javac.
I must say that it probably would have saved me a lot of time using an IDE for my initial developement classes, but I feel that I've gained a much better understanding of what is going on and I'm a better programmer for learning things the "harder" way.I couldn't agree with your statements more. Our introductory computer science course (a "primer" for non-majors) spends the first third of the class learning how to use Linux. In my opinion, this is the dumbest use of class time possible. There is absolutely no value in knowing the Linux prompt; all this section of the course does is show students how to use the command prompt to traverse the familiar filesystem abstractions instead of a GUI.
This Linux ramp-up literally serves the sole purpose of getting students ready to use gcc when they learn C++ in the next third. Intro students would be better served by learning more about what it means to write a program. Frankly, I would be more than happy to have intro students learn VBA to script Microsoft Office.
The point is that intro students should learn why computer science is useful, and how computers can be put to good use in general. I know too many people who spend hours doing repetitive tasks that I could solve in 10 minutes with a short script. Intro classes should show students, at the very least, when asking a computer professional for advice can save them lots of time.
Let's see, looks like it's now the 21st Century. Go with the IDE.
I took a Java course and the first day we ever did programming it was on a IDE and for the longest time I had no idea how Java internals work. I still cannot compile a java program from the command line as I have never tried I've gotten so used to the IDE that I don't even bother learning. However when I learned C++ independently I started without a IDE and developed a greater understanding of C++ from doing so. It makes more sense to start without one then integrate it in at a later point in time that way they get the full spectrum of programming environments.
I thought an IUD was standard procedure for college co-eds-
For me, one of the main points of using an IDE is because the creation of make/build type files is automated. Different ideas of automation, I suppose.
In my courses, we were not given typing lessons on how to use an IDE, or vim, how to compile with VS or gcc.
They should be allowed to use what they like, so long as they can write code that compiles for your test environment.
-- (appended to the end of comments you post, 120 chars)
I would personally teach with an IDE, but allow the use of any IDE (this is what I've seen done in most of my classes before). However, it might be a good idea to explain that the ide isn't needed, and that it's just to help the programmer. If there are any tests or exams they have to take without an IDE, it might be a good idea to prepare them for that sort of coding too.
Then why is everyone suggesting, gasp!, notepad as a text editor?!
HARD DRIVE CABLE
My take on it that students should be taught to use the standard command line tools, they need to realize that the language is independent of a particular IDE.
once they know that, they can start using an IDE.
Omry.
I would say don't worry about using one, it can help simplify the build process (which can over complicate things at first), but they shouldn't be using the IDE to generate the code for them. Later on though, I think it would be best to actually talk about what it is and how it can help, along with covering using a debugger. The debugger can be one of the most powerful tools, but figuring one out on your own isn't exactly the easiest task.
I don't know everything.
To stall at the point of building by hand and not continue to learn and gain the productivity advantage of the IDE would be a mistake with measurable consequences.
At the same time, becoming dependant on an IDE without taking the time to fully understand the mechanics of software development leaves you ill prepared to diagnose the inevitable problems that will occur with the IDE.
As far as editors, sampling a variety might be a good idea before settling on a favorite. I'm comfortable with visual editors but find 'vi' invaluable for some tasks outside source editing. For source editing, anything that formats well and color codes the source is fine by me.
Some people feel that expertise with primative tools is some how macho. I value my expertise gained "back in the day" but failing to get comfortable with modern a IDE is failing to become as productive as you could (skipping the IMHO disclaimers here).
"We demand guaranteed rigidly defined areas of doubt and uncertainty."
-- Adams, Douglas
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...
Any sufficiently unpopular but cohesive argument is indistinguishable from trolling.
Look at it this way. A parent is teaching a child to build a dog house. The parent explains that the nails hold the wood together, and for that to work the nails have to be straight and true. The parent then using increasingly difficult tasks and teaches the child to use a hammer to complete this task. Note that if the child did not understand the goal of a hammer, the child would not be able to adjust to the proper use. Also note the parent did not give the child a rock, as we have hammer technology that is very mature. Also note that the parent did not give the child a nail gun as that would not have taught the concept. Also, depending on what the child might want to do, he or she might have to be very skilled in the use of a hammer, as a nail gun might be inappropriate for the job.
So here is what I think, and generally the way I was educated. Start with the basics, which is process development and flow control. Have the students develop incresingly complex processes. Examples might be getting ready for school, sharpening a pencil, washing clothes, etc. The processes should be personal and common as they must develop the steps themselves, not just copy instuctions.
Once they understand the basics of process, they can start working on the standard cannon of practice programs, i.e. 'hello world', and convert the process into a standard language. What the standard language is, and how it is used to compute the solution, depends on the expected outcomes and needs of the students.
Specifically, many say that the kids should use vi, ed, or emacs. The question must be asked are those tools the kind that will useful for developing the complex code that are expected to develop. Unless these kids at CS majors, is the overhead of learning the command structures of these application of any use, in other words are the opportunity costs justified. The kids must know the baics of code development, and the generalities of modern languages, as well as specific languages. But why make it more difficult. When I was in middle school we started on a teletype and in high school moved to a VT52, in college a VT 100, then quickly to an IDE on microcomputer. Did the school ever make me work a card punch? No. Did it do any harm? Maybe, but not enough to justify the loss of coding time. Perhaps I should have been taught to hardwire code?
So I gues what I am saying is don't look at it from a tool point of view. Look at it froma concept and objective point of view. Introducing advance tools will reduce skill, but it will also increase effeciency. Very few people are going to have to do assembly any low level code. For the most part, people will put widgets together to form large applications. To be honest, most people will just use a macro language to write scripts. If they understand the basics, they will have a huge advantage over thier co workers. Those that are going to low level stuff need to be in classes that caters to those details, and those that aren't don't need the distraction. This does not mean that the kids don't need to know the tools. Start in a text editor. Play with gcc. But they can learn much more of the language if they ar in a simple IDE and not fighting with the tool. Furthermore, when we are taking very high level languages like Java, with heavy API dependence, not using and IDE is just going backwardsOn that VT100 I wasted a day because I forgot to reset a redirect. Was it a good lesson to learn. Yes. Did it prevent me from learning even more useful stuff? Absolutely.
"She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
I have to say if you have the opportunity to teach vi and command line tools then DO IT. I have seen too many "professional" programmers that have no idea how to do the stuff that an IDE does for them. They don't understand what those check boxes mean for build properties. They don't understand what is being generated and how it works. They just know "push this button and I get an EJB."
I think people need to start taking the mentality "if I don't teach them the right way then nobody will," because every other teacher isn't even considering this question right now.
This reminds me of a CS student who had gotten his degree without having to program C/C++ because there was a big Java push. Every professor allowed Java so none of them taught C/C++. In the end you get students who don't know the first thing about low level programming walking out with CS degrees. The same is true for command line vs ide. Some students will go through the paces without ever having to invoke "gcc" or even "javac" or for crying out loud "ant" or "make".
copy con file
Members of my own team are useless without Visual Studio.NET IDE installed. I once had a peer who had his computer replaced, but could not VS.NET installed on his system right away (because of some weird license issues). He needed to compile a couple of files together to create a single executable. I pointed out that if he already had the .NET framework installed, a compiler already installed also. He could have used the command-line compiler, but admitted to me that he could not. The reason: the school where he learned how to program did not teach him. After polling other people, I was shocked that about 75% of my team does not know how to use the command-line compiler, either. My jaw hit the floor.
So, I would teach your students without the IDE at first. Let them learn how to code in the editor of their own choice. Expose the compilers to them from the command line. Fundementals first. Leave the IDE whiz-bang time-savers for future training opportunities.
Coderz 4 Life
If you don't have strong feeling either way just see what the prevailing attitude is at the collage and follow it.
As a student, I would say don't introduce an IDE until you feel they can really appreciate what it does for them. Our professor just started out recommending we use vi, and gave us all the information we needed to compile the programs using a makefile.
Being a windows user, I gave up on vi after a while (yes, I'm weak :<) and started using TextPad to edit my files. My professor never really introduced us to IDEs, instead he simply mentioned them in class and gave Eclipse as an example. I played around with it for a bit, but it wasn't until we were doing programs with many classes that I thought "maybe this would be easier with an IDE."
It worked out well. At that point I could say "Wow! It does all this for me! Now I can procrastinate even more!"
In conclusion, I really don't think you should teach with an IDE, but don't discourage the use of one. By teaching how to program without an IDE you really give students the knowledge they need to properly use an IDE in the first place. That way, rather than using it as a crutch, they use it as a tool.
IDEs are a great tool, but they can often obscure the details that one should know too. For instance, I know a lot of people who use Visual Studio who would be lost if they ever had to use make files or script-based configuration/build tools.
:).
I myself learnt to program on an Apple ][e with BASIC, and later graduated to using M$ QBASIC on DOS 6.0. The former, of course, didn't have an IDE, but still ended up teaching me a lot about modularity and thoroughness, whereas QBASIC taught me how powerful an IDE can be, provided you have one.
If you can figure out a way to have a different set of exercises, one which targets IDE-based projects, and another which teaches survival skills using the command line to use the interactive shell for the language you will teach, or to use tools that the language distribution provides, that would be great.
I mean I would have loved to have been taught that way
Comment removed based on user account deletion
SATA is much better
No IDE, then after they pick up what a compiler is, and a few options...
Then teach them the IDE.
Non impediti ratione cogitationus.
As progress is made, it's important to incorporate our technological advancements in teaching the next generation. Teaching programming without an IDE is like teaching tailoring starting with a cotton gin. It's important for historical significance to understand how things were done by your predecessors, but that doesn't mean you should start out learning how to do everything the same way they did.
I've listened to many discussions about the proper point to introduce a person to IDE usage. Two major reasons people argue not to use an IDE are:
I disagree with both points. On the first point, IDEs increase students learning capacity because they are not distracted by minor technical details that are not directly related to the concept at hand.
On the second point, although scenarios exist today where IDEs are unavailable, it can realistically be assumed the number of such scenarios are going to diminish as we move towards the future.
IDEs should not be treated as a gimmick or luxury. They are an integral part of many development environments. The goal of learning programming is to teach students how to solve logical problems. The usage of an IDE allows a student to focus on the logic problem, where the focus of human attention should rightfully be, instead of mulling over minor syntatic mistakes, the correction of which can be automated.I have had some recent experience with this issue. Our course which is pretty much set in stone by the department is an intro to programming which teaches java. The class is pretty fast paced though it is available to a wide range of students, Arts, education . It is aimed at just in terms of time/pace people who are pretty serious about learning how to program but have close to 0 background. Pretty much a crash course...and many crashes. For some reason the school chose the eclipse IDE . This was a bad choice for a few reasons. 1. There was this whole process of getting it all set up with the current version of java. Many students had problems. It required the first week to pretty much just be a tutorial in setting up eclipse. 2. Your TA's may know how to program, but if someone has been working on a phd in theoretical computer science for the past few years, they probably wont be of much help answering questions about why ecplise wont work. 3. Even once it is properly set up students still have problems. The interface is perhaps not so intuitive for begginers. 4. Though they might be totally disgusted with the command line , its still the most sure fire way to compile. 5. the first intro tutorial week gives a false impression that the course will be a cake walk and that they will be hand held the entire time. Week 2 can be a very rude awakening. my stance at this point is : Teach most basic command line tools. If they want something more and are capable of going and figuring out eclipse, etc...more power to them, they will probably learn more this way. you dont want to be wasting everyones time learning the latest and most robust profesional IDE which will be long gone by the time these beginers are anywhere near a position to take advantage of them!
... 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.
Help poke pirates in the eyepatch, arr.
I find myself agreeing with everyone (a /. first?). Myself, learned to program on an early PDP (N less than 8 but I can't remember how much less). Wrote the binary program directly in
a 3-ring binder (ever wonder where the term "page" came from re RAM?) since we had no
assembler available. Entered the code with front panel switches and/or paper tape.
Well I learned a LOT about how a very basic CPU works at the bit level. Modern CPUs
are very very much more complex -- but the underlying mental model of languages
like C and its offspring is exactly that primitive old CPU. So going down to the guts
has some benefits. BUT, some years later concepts like data abstraction, functional
languages, etc were invented. I found that the interpretive nature of LISP for example
made it MUCH easier to understand, implement, and debug programs using these techniques. LISP does not, IMHO, try to present a program representation that looks at all like that old primitive CPU, or indeed any CPU. And yet data abstraction (of which
OO is a subset) is certainly a vital thing for almost any computer literate person to
understand, plausibly more important than undesanding indirect memory references or interrupts for most folks. I also later learned to work with programs that were not
examples or toys, and they always turned out not to be "a program" at all but a largish
collection of interrelated programs, headers, etc. That's where IDE's are really good.
Last point. I last did programming "manually" (no IDE) when "make" was new. Nowadays everybody uses automatically generated make files that are basically not readable
by humans. Personally I use an IDE on the few occasions I program at all anymore, so no make files. But I have to figure out and at times correct packages that come with a zillion c, cpp, h files etc plus unreadable make/imake files (or worse) -- there must be tools that will take these configuration control file things and translate them into something a human can understand, so that one has a chance of finding which one of the zillion modules one needs to fix and/or modify -- clue an old dino in: what's that tool called (Unix/Linux
environment please).
Even laster: the whole point of python and friends is to hide all of this stuff, so just use whatever makes life easy if that's what you're teaching. Still won't simplify the hardest part: thinking hard before coding. To teach that, I suggest changing the requirements for medium size class projects every few days up to or even including the day the project is due. This will teach respect for the importance of clean, well-structured design in any language. It's also a lesson in how the real world of programming tends to work.
In my opin, it is just too much to learn, this wierd new program and trying to get the concepts of what coding is. Programming is a whole new world for most people on a computer, new software, new ways to think. I would recommend something very simple like SciTe or an easy to use programmer's editor. Simple, with some ready to use macros. That is all you need to start coding, then take them to using IDE's and projects in those.
The phrase "more better" is acceptable English. suck it grammar Nazis
Teaching them to use a specific IDE would be a waste of time. From what you described they should be at least in their second year of college. By then they should be able to select their own IDEs.
The course should be focused on learning Java or Python. Don't turn it into an Intro to Eclipse, Netbeans, etc... course. If you plan on doing in-class lab exercises you might want to select a few common IDEs for them to use. Otherwise, don't make assignments or tests about the IDE instead of the language.
What you can do is give them is a list of IDEs that they could try out. If you narrow down the course to a specific IDE you're just restricting the students.
Learn with the IDE, since learing the IDE is a job within itself.
Whoever modded this insightful is retarded (it's not insightful, the mod just agreed with the sentiment). Oh really, when you aren't trained how to fly a plane you'll crash it? Isn't that the goddamn metaphorical point?! If you aren't trained how to program you'll crash it. Well yeah, duh, that seems pretty apt to me.
If you really are learning-disabled, then I am symphathetic and empathize, but it sounds like a hollow excuse "I can only learn by trial and error". Imagine how long it would take kids to get through the third grade via trial and error (spelling by trial and error), how how about English Lit (essays by trial and error?!). I know it hurts, but sometimes you just have to learn what's right the boring way: from a book, from a lecture or from an experiment. E.g., you'll fail physics if you design your experiments by trial and error or don't perform prescribed experiments because you want to just figure it out by trial and error -- ignoring that this is in some cases extremely dangerous. My point: Computer science and computer engineering aren't uniquely special fields that require all these crazy new techniques for proper/effective instruction. Again, making exceptions for the disabled.
IDE's come and go like fashions, but the underlying language (or at least the concepts) tend to be relatively stable. Given that you're teaching programming anyhow, I really can't see any reason to add the overhead of also learning an IDE that will probably be replaced soon enough anyhow.
or so says some articles I've read. Come on, people. It sort of encompasess the top level perspective vs hands on approach. Once the lower level tools are "stable", it makes sense to create higher level tools that manipulate the lower level tools in convenient automated fashion.
Yes, some creativity is stifled by limiting ones scoop to a set of tools at a certain level. But the gain is the ability to worry about higher level problems. Hopefully this focal shift will lead to an increase in overall productivity.
"Recursive bipartite matching"- try it!
i've just gone back to school for a bit and the instructors at the college got us started using scite for java (works for any language).
it has the advantage of looking and acting like a basic text editor, but is highly manipulable using text based configuration files
so you can set it up to do a build or make directly from the menu, but in order to edit the config file you have to know how to do it on the command line properly
As someone who learnt without pretty IDEs...
We don't insist that people learn assembly code before they learn C and Java. We don't insist people turn assembly instructions into machine code by hand. We don't insist on learning electrical engineering skills before putting machine code into RAM. The way this is taught is to cover the basics first of all, then go into detail about assembly code at a later stage, and if someone goes that far, look at compiler technology and opcode generation.
Starting students should be using nice, friendly GUI IDEs. More advanced, specialised courses should go into the details of how to work without them. Think of it as another layer to dive into later.
Yes, the best developers will know how to work without IDEs. Just like better developers code higher-level languages with an awareness of how the code will be compiled. But there's no need to force that detail onto someone in an introductory course, just because we had to do it.
If your goal is to teach them programing fundamentals, you should skip the IDE.
However, according to the post this is a intro to Java/Python class and it sounds like it has non-trivial programing related prerequisites (1 semester in programming in C++/VB was mentioned). Therefore when using these skills in the real world, they will benifit from having experience with the tools of the trade, and in the Java world the IDE is king of tools.
Teach them how to walk first, show them what is going on under the covers, and once that intro is done, switch to the IDE, demonstrate how the two relate, and don't look back except at the mid-term and the final. The IDE can also be a very powerful teaching tool to help graphically demonstrate things like Class hierarchies, and how important good documentation can be made an integral part of the experience.
If this sig is witty, it was probably borrowed from someone else's sig.
When I learned Java my instructor made us use a program called Bluejay. I think it is a good platform to learn on and it is free. It is specifically designed for teaching. You can find out more info at http://www.bluej.org/
Should Students Be Taught With or Without a Monitor? We can't spoil students today with these fancy programming aids. They should be making their punchcards and deciphering the results in hex-lights displays.
I had to take an introductory course on Java a couple of years ago, even though I am fairly proficient already. But the course came in two flavors: one course in "object-oriented programming" (my course) and one in "java programming".
My course used the extremely simple IDE-ish BlueJ (http://www.bluej.org/). I think it was really great for all the non-programmers, because it allowed the teachers to start where you should: at the conceptual level. The other course started with syntax, compiler commands, files and Javas idiosyncracies (only one public class per file etc). They even spent an hour learning unix commands before they could start programming!
We started straight at objects: instances vs. classes, inheritage, methods, instance variables. BlueJ makes it simple: You open an example project (for instance a "shapes" program), and then you can instantiate objects and run their methods through a GUI. The objects even appear on-screen with quasi inheritage lines!
If you're teaching Java AND Python this object-oriented conceptual approach will be invaluable, in my opinion. And BlueJ is free as in beer.
Roses are #FF0000, violets are #0000FF, all my base are belong to you
If you really want to teach "intro to programming" class, don't bother about showing them "under the hood". Select simplest IDE with hinting, error highlighting, so they spot problems more quickly and learn what you want them to learn.
For Python I'd recommend DrPython or like (PyShell/PyCrust/PyAlaMode).Never seen beginner's environment for Java though.
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.
Why not just stoping teaching and have the students figure everything out for themselves.
The point of teaching is to not let your students hang there head on the walls against stupid problems.
What good is learning a programming language if they don't know how to compile the program on systems without the IDE?
Every programmer should know how to use a typical unix terminal. Since most of the students have already had a programming course, they should be able to handle it.
Regardless, I don't understand how it would affect your teaching style, unless they're all watching you program... If you're teaching the language, teach just the language...
Buckle your ROFL belt, we're in for some LOLs.
Use an IDE and tell them how to use the debugger. Make sure they also know how to use the command line tools. Don't require them for all of the projects, but be sure to put it on the test.
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.
A favorite professor of mine once quoted "teaching is a practice in diminishing deception."
:) )
First, you teach them with an IDE so that they "get something to work." [The IDE is like the training wheels]
Then, you take the IDE away (say, in a 2nd or 3rd semester course) and let them understand what's under the hood. [You take the training wheels off]
Finally, you give them real problems and let them come up with the solution [They can drive a car, ride a motorcycle, or take mass transit]
Good example of how this was done at my school:
1st course: C++ using Visual Studio
2nd course: Data structures using UNIX (editor of choice) & gcc
3rd course: Assembly language (What's an IDE??)
4th course: Operating systems using UNIX/C++
5th course: AI using LISP !!! (at this point, you _need_ something to do paranthesis matching
I'd say keep the IDE for Java, but be sure they can actually write code on paper...
Learning the nitty-gritty details of a language is absolutely necessary to program successfully in it. However, for an introductory CS course, the nitty-gritty details of a language shouldn't matter. In fact, teaching it in a language with as few details is possible is probably best. I learned to program in Scheme (no, I don't go to MIT) and I must say it was probably the best thing that could have happened to me; Python, used in conjunction with an IDE, would probably be just as good. Worrying about what needs to be included in your interface has nothing to do with OOP and everything to do with Java. The fact that I learned about everything conceptually long before I ever actually programmed anything has made me a much stronger coder than I would otherwise have been.
And, if you must use Java (a ridiculously verbose caricature of a language IMHO...) definitely use an IDE. You will spend more time trying to get people to type the right sequence of commands than actually teaching anything about CS if you try to use javac to do everything.
IDEs allow you to step through the execution, to see what's happening. They remove tedium. They also often have useful syntax markup - specifically in the case of Python, this is important. I've used a python IDE (SPE) that shows how your indentation breaks down into execution blocks. That's very important for python editing, and giving your students help visualizing it is probably good.
Other than that, I agree with other statements that IDEs are fine, as long as you understand what's going on behind the scenes. Specifically with java, showing them that java programming essentially uses only 3 executables - the editor, the compiler, and the VM.
Powered by Web3.5 RC 2
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.)
"You've crossed my Line of Death!" "What? No! Where is it?" "Here in the fine print...."
What are you trying to teach? VI? Emacs? or are you trying to teach the programming languages?
Why make it harder than necessary? Just to slow them down by doing things the 20 year old way?
Or just trying to preserve the tradition of doing things the hard way?
If you want to teach the languages, worry about that. They can learn vi and/or emacs if and when they need it.
Speaking as a non-programmer who has taught himself a middling amount of Java (and C#) and a slightly less middling amount of Python I say, for a community college course (which I assume is going to be pretty oriented towards practical programming, rather than computer science): For the java course, use an IDE because that's what you do when you write java. For python, I say give them a decent editor with syntax highlighting, and show them how handy it is to be able to use the interpreter interactively and do 'dir' on objects, even without some big IDE.
Back in the bad old days when I was being taught to program, we had to write everything out by hand then review it, then when it was agreed it was reasonably correct, type it up, check it again, then eventually compile it. The more compilations the less marks.
What a complete waste of time and energey it all was. Of course you should use and IDE to get people started. The more enjoyable and the easier it is, the more likely they will stick with it and want to explore later.
Seems to me the answer depends on why the students are taking the course--are they training for a future job, or is this course meant to be transferable to a degree program at a four-year university?
I teach physics at two very different community colleges. At one, the course is intended to meet the prerequisite requirements of both of our local universities, while the other college is a technical school, focused on job training. While the course and the material is ostensibly the same, the emphasis (and therefore the student experience) is utterly different.
If this is intended to be transferable, you (or your department head) needs to contact the local universities and determine their transfer requirements.
Cheers,
jIyajbe
"Don't blame the log for the fire." --Andrew Ratshin
The first 2 years you should teach them python| C | C++ |Java only using an editor with syntax highlighting like vim, gedit, kedit, or even anjuta.
Only when they master the language thought and only then you may pass to a more advanced IDE (this is not mandatory, due to the fact that in the begining the student should also be concerned with the syntax of the language.
IDE's are great for getting past a lot of details of computer languages. It seems that there's a general consensus that a beginner working with an IDE will lose these details... but I have to think, "so what"?
Actually, so what is the goal of your course? Is it learning a language to know it's details, or learning to use a tool to solve problems? I can see valid reasons for both approaches.
Focusing on the language ability is a tremendous skill that forces people to understand the weaknesses and strengths of their selected tool. It's a critical trait I look for in a professional programmer, because that guy you hire that doesn't understand the language ends up writing code that you have to fix or rewrite. But then again, this is school, not work. And focusing on the language can also be a very dry subject to many people.
Focusing on solving problems can be a great way to inspire interest. If you can find interesting problems, your classwork will have a nice "approchability". The best problems also inspire the students to find their own nuances. Ergo, say you're going to make a pong-like game. This is great, since your inspired students may actually take on tweaking the game quite a bit to make it do different things: add more pads, more balls, obstacles, etc. If you can get to a "theme and variations" aspect to your problems, the students will probably learn more than hammering them with language details. (And, in fact, it may serve to have them find out the language details on their own, and asking good questions...)
I guess I'm coming from the opinion that school is not there to create professional programmers. But some people, and students, go to class just for that reason. Ergo, it's a grey area. But my advice is to use the IDE, and have the students do something complicated, rather than making them jump through hoops.
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.
Vim.
I taught (and probably will teach again) introduction to programming for EE students. We use C++ as the language. We only have one formal class to teach programming. Thus, everything has to be packed in one semester. I decided to use command line (and sometimes the concept without computer).
My thinking is, if you want to teach a kid how to communicate, you don't ask her to use a sophisticated dictionary. The most important thing is she understands how to communicate. The language of choice is just to make it easier for us (teacher and student). Imagine teaching a kid with different languages at the same time. Make it simple.
IDE was introduce as a show-and-tell so the students know what's available out there (what's being used by professionals).
If this is an intro course, you probably should be going over the basics in the language, not showing them how to use an IDE. Give them the freedom to choose their own editor, but challenge them on the language.
:)
All ya need to do is teach them the basics, provide a reference, then give them assignments that go above an beyond what you've taught them by a slight amount. The more they learn to grep the reference on their own and not be dependant on a human to teach them the better off they will be in the long run. Today it's Java, tommorow they are on their own with the boss breathing down their neck while they are working with a new language they have never seen before written by a developer that moved on to another job, and they are gonna have to know how to pick up the language in a hurry.
If there are no courses required that are programming related before this course, teach them print debugging for one class, after you've taught them what System.out is.
And if you could do more of what most of my teachers never did and teach them to catch and deal with errors from the beginning and burn it into their minds you might start quality developers out into the world.
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.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Syntax highlighting and paren/bracket/brace matching are a must. It shows when you've screwed up and where. To me this is the most useful part of an IDE. The only other part of an IDE that I generally use is any function reference it may have.
So, basically what I'm saying is that you should use syntax highlighting, brace matching and a function reference. The compilation and project management should be done via command line.
Now that I think of it, though, code completion (like methods popping up when you type "object.", with the parameter types available) is useful and generally won't hurt a student's learning.
Calculators, and you're now back in the early 90's in regards to maths. As long as there's a fundimental understanding of coding, (i.e. their BEDMAS in maths terms) I can't see why not use an IDE.
seriously: even considering teaching in an obsolete tool (except for seasoned sysadmins) as vi borders on criminally insanity. I suspect that you are one of the legions of shit TAs out there that plague american universities. Pity.
What kind of course for what students? If you teach computer sciene students and the emphasis is on the concepts of the languages, do not use IDE. Using the IDE needs learning too, will take away time from what you really want to teach and is useless because most programming projects will be very small. Let them use whatever editor they like, on whatever OS they like.
If on the other hand you teach a course on actual programming for future commercial programmers, use not one, but several IDEs and let them program actual projects where modularization, source code-dependencies and version control are issues too. However, that will still need a lot of additional time so it would be better to have seperate courses for the introductory stuff (no IDE) and advanced stuff (IDEs and more realistic projects).
I would use an IDE, for the very simple reason, they wont be typing code in a text editor if they get a job coding. If you pick one pick Eclipse, http://www.eclipse.org/ as it is the one that is most likely to be used in the real world. Also as there is so many APIs in java with their imports that most students will forget about what to do and will not enjoy the experiences so they are less likely to do their best work. Just my 5c worth
Access Point Live Mapping Access Points with Google
You could possibly get away without using an Integrated Drive Electronics (IDE, i.e. PATA or SATA HDs, CD-ROMs, ...), but it'd probably be a bit expensive - SCSI isn't cheap.
;)
Personally, I'd recommend you go with the norm and use IDE. It's what they'll be using when they grow up, anyway.
I submitted an "Ask Slashdot" question about whether students should be taught
programming using a regular mouse or an optical mouse - wonder why it got rejected.
Why not have them do *both*?
Start them out in a normal text editor -- vi/vim, emacs, Notepad, etc.. Then, after a while, have them use the IDE. That way, they get to see the progression that has occurred in the actual practice of using a programming tool. They will see firsthand how much nicer it is to be have the IDE do all kinds of grunt-work for you (building a GUI by typing in (x,y) pixel coords vs. click-n-drag the window and control sizes you want, etc.). They will also see the value in having a lightweight text editor around for looking over log files, etc..
As with learning anything, a broad set of experiences lets you see what is available and make an intelligent decision as to what your personal preference is. In this case, it will also provide a bit of historical background... (i.e., "in my day, when the brontasaurus was stepping on programmers who compiled using MSFT tools, all we had was the command-line and a text editor like this..." - much to the horror of students who didn't know a "command prompt" ever existed.)
Is Capitalism Good for the Poor?
I see most people are saying not use a ide but do they have experience teaching or are they teachers who hate the students? What are they trying to teach, programming or patience and neatness and the memorisation of al kind of particular shit? I do have experience teaching. Using a good ide gives you a lot of precious time to really teach programming. Learning programming is difficult enough the particulars of compilers is a different course al together i think. Use somthing like drscheme or bluej and maybe even prepare some code your self that they can expiment with and change. Do not throw them in at the deep end of the swimming pool!
Anyway, kids these days... back in my day we had to type the bootstrap code into the system by hand! In octal! And we liked it that way. I know someone with a master's degree in CS who can't explain to you what a linked list is, much less code one. They just don't make 'em like they used to...
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
I think they should be taught with a SATA ;-)
One that has syntax highlighting and possibly symantic checking, but all compilations, runs and source organization are done from the command line. I don't know if any editors like that exist. Since your students already know how to program a little bit, I think going back to paper and pencil is a bit extreme. However, syntax highlighting is a must, it will allow your students to recognize and learn the various structures and keywords faster. Try it yourself, open up a source in notepad and try to quickly see what it does and do the same thing with another piece of source in a syntax highlighted IDE.
The question of whether a computer can think is no more interesting than the question of whether a submarine can swim.
Ignore all these fools telling you to use emacs or vi. Your audience will be used to using Windows programs, and if (as you say) they've been doing VB or C++, they've probably been using Visual Studio anyway. You might as well let them continue. If you try and force vi or emacs on them you'll be wasting valuable time teaching a cryptic and outdated UI. Leave them with what they're used to for editing. Anything else will just get in the way.
Don't teach them in a full blown IDE. But I'd say definatly use some form of advanced text editor like TextPad with color formatting etc. It will make it easier to learn without so much of the dependancies.
I would definately teach with an IDE. But for me the reason is not to prepare them for the job where they have to know IDEs. In my opinion it's seldom a problem to get to know the toolchain used once you start working somewhere. The real question is what is to gain from not using an IDE? In my opinion it's not much. The students will probably have better syntax skills sooer because making syntax errors is much more time consuming than with using an IDE. They might get to know the languages apis better but that really depends.
With using an IDE they can concentrate more on the programming side. They don't waste valuable time fixing stupid syntax errors or searching for why there are errors. They are even sometimes told if they produced not so ideal code. IDEs like eclipse support certain kinds of refactoring pattens. If it's about the patterns there's nothing to be gained from actually copy and pasting a method to the source file of the parent class but from applying the concept.
In my experience you can learn a language much quicker with a good IDE because it guides you with all the small things you usually have problems with in the beginning and you can therfore concentrate on the programming much quicker. But you will eventually also learn the small things eventually and then the ide just makes you be more productive and focused because it helps identify the occasional typo. That's especially usefull with languages having huge libraries like Java.
New students shouldn't even get an editor. I say keep it simple; bang out the cadence of ones and zero with your head against the desk. If your app compiles, the university covers hospitalization and rehabilitation costs. If not, piss off, because this is exactly what programming for most corporations is like.
You never said what kind of class this is. Are you teaching CS students or MIS students? Or business students taking a few programming classes as a submajor? It matters...
sink or swim. don't teach an ide. those students who begin using notepad and fail to grasp the limitations of their medium will sink, and that's a good thing, because they shouldn't be programming. i know it sounds harsh. i started with DOS edit, used it up to college, then was forced into vi by lack of alternatives (other than emacs, whose philosophy i completely disagreed with). after trial by fire i'm now an expert vim user. i guess what i mean is, let students find what suits them best, and those with no real opinions after surveying the field should pick a different career.
Hey, I'm a teacher in an elementary school. Next year I will be teaching adding and substracting to a bunch of kids. I was wondering what the prevailing wisdom is when it comes to teaching arithmetic- should students be taught with or without a pocket calculator? I am a bit old school and wouldn't mind having them all use pencil and paper, but using a good calculator does have some advantages as well. I should note that the students I will be teaching already manage to use both their hands to add to ten, and in summer, to twenty. In the end, after all, they'll be all using calculators to perform those operations, and there will be lots more of time to teach other things if the lesson for teaching to add consists simply in showing them the + key.
Rome taught me patience and assiduous application to detail. Virtues which temper the boldness of great, general views.
When it comes to programming there are actually two things to learn:
- Knowledge of the language and runtime libraries.
- Knowledge of the development tools.
So personally I think that it is best to learn the tools of the trade first with rather simple and stupid programs and then learn the language using the preferred IDE for the task.Anyway - when teaching a programming language there are two parts to consider too, and one is the language sematics and another is how to break down the language in useful modules. You can actually cut even more into the art of programming, but I think it is essentially to teach how to think modules since newbie programmers tends to think in a huge blob resulting in the famous spaghetti programming syndrome.
One advantage of an IDE like Eclipse is that it has support for breaking out code to a separate java method with a simple operation. Other IDE:s may have similar functions.
And don't forget to mention programming style, which is important, especially the generic variable naming shortcuts that can be taken (i,j,k,i0,i1 etc) for index variables instead of longname index variables that tends to clutter the code.
When it comes to code formatting I think that the guidelines offered by JavaRanch is a good start. Most formatting rules can actually be applied cross-language. Any decent IDE will allow you to do code formatting and can be configured to the preferred style.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Emacs (and I understand vim as well) can easily form the core of a text-based IDE (that was after all its intended purpose). So I gather what you're really asking is whether one should teach via a graphical IDE or a text-based IDE. This is a different flavor of question than whether or not to teach with an IDE at all.
was done on TRS-80's on LOGO, and THAT had a system vaguely like an IDE, I'd say this entire discussion is rediculuous. Why don't you start doing entire four year degree's entirely on paper, no computers at all!
During your lectures use a number of environments, starting with a text editor (no syntax checking etc). By the end of the course the students should know that there is more than one way to write code and some of the pros and cons of each.
For most of the lab exercises use an IDE, but provide emacs if they want to use it.
It is totally inconsequential what development environment students are taught with. I would be more worried about what students are being taught, rather than what tools they are using. Stick to something simple that doesn't require learning key combinations to use. You have limited time to teach a degree, and you don't want to be wasting that time on learning how to work a text editor. Anyone can pick that up later on with now problem. Most importantly, I would think that students need a good understanding of underlying computer architecture, how high level code ultimately is ultimately implemented as machine code, and exactly what the abstractions of a high level languages actually mean for the underlying code that is generated. I would be looking at the acutal machine code output from a common compiler, and showing exactly how it the native code maps to this. There are too many 'programmers' coming out of universities now who do not fully understand the implications of how they write code on runtime efficiency, and make stupid mistakes with things like pointers because they don't fully understand what they are actually doing. A good software development degree must include a strong understanding of low level architecture. A good degree will probably include at least the equivelent of a first year maths degree as mathematical content, covering applied mathematics that is generally applicable to Computer Science (ie. geometry, matrix algebra, ...). Do you want programmers who can't implement basic statistical code? programmers who don't understand how to detect when a user is clicking on a line on screen? programmers who don't know how to use matrics to make 3d projections? Design of software is important. Java/C# is good for teaching OO design. I would suggest that Visual Basic be avoided at all costs, as it often seems to lead to bad programming practices. C++ is probably too complicated for a first year course, but I would be looking to at least provide a solid introduction to it in 2nd/3rd/4th years. Common algorithms and Data structures, and their impact on efficiency are absolutely essential. Programmers who use common libraries should be able to understand 'O' notation, and evaluate the effects on things like insertion, deletion, and element access speed on common data structures, and select data structures appropriately for the task at hand.
I first give my interns and trainees a CLI rundown explaining them the heritage of VI & Emacs and why they are such nutcases in operating and show them ssh, grep, pipes, etc.. Then I move to jEdit. jEdit is used for showing of jDiff, Regexes for search/replace and a bag of other cool jEdit-rules-all features and plugins. If your focus is Java dev'ing I'd make a stop at jEdit but then move on. It's to cool an editor not to check out some features and learn to use it. Anyhow, with java you'll want to move on to an IDE to streamline collaboration, toolkitting and GUI-building, even though editing itself will be worse than with jEdit. Here, of course, you've got two choices, Eclipse and Netbeans. If you're on Linux only add KDE Studio/KDevelop and Erics Python IDE to that.
Both Eclipse and Netbeans are top-of-the-line and it's up to personal preference which one you teach.
My rules are:
1) Bash CLI is to cool, usefull, praktical and omnipresent it would be irresponsible not to teach a little of it.
2) It's irresponsable to teach anything other than OSS tools. OSS is better and has more features than most people will ever use. If they wanna go MS afterwards, it's up to them. I (you) warned them.
It's OK of course to give your students a peek if you have a favourite commercial tool - especially if it's Non-MS. IDEA comes to mind as a potential candidate. But don't do that for more of a day or two and not without explaining *why* you think it's fair to shell out money for the tool.
Whatever you do, never forget to warn them of MS and protect your padavans from the dark side, Master Cliff.
We suffer more in our imagination than in reality. - Seneca
An intro course should definitely focus on the basics and not worry about teaching with an IDE. Many of these students aren't going to be Computer Science majors and don't need the distraction. I do recommend higher level courses require use of Eclipse, MSVS, or whatever else is popular.
Vi, Emacs, or even pico are good for the beginner if you don't focus on the many keyboard shortcuts. Personally, I liked the UNIX based systems and the exposure might spark the interest of students looking for a major.
Just to chime in with a case story.
/Fjodor
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.
"The number you have dialed is imaginary. Please rotate your phone 90 degrees and try again."
I remember the first course I took in Java at a community college, we had to do all our programming in notepad and goto the command line to compile and run it. When I went to university and had to do Java programming they recommended Dr.Java. As far as IDE's go it is minimal, basicly notepad with syntax highlighting. It also captures the command line output in the window and lets you compile and run code with out having to goto the command line.
If you search for Dr.Java on SourceForge.net you'll find it.
I taught my son how to program when he was about 10.
We did the first 10 or so little programs with just an editor and the javac. It was much easier to see how things worked that way.
Then we moved to eclipse.
It worked well. I think it is the way to go.
The really interesting work happens in my head when I am studying source code or looking at a list of requirements and coming up with a solution architecture or model. An IDE cannot even come close to that, and though I do understand what an IDE is doing it and could figure out what command line tools it is using, I'd prefer to just move on to the more interesting and important aspect of development.
When I see people saying, "Oh, no. Make them do it without an IDE so they learn those fundamentals," I am a little astonished because honestly, if you really need to know how to compile a program from scratch that involves using a command line tool and the second you get into a nontrivial project, you need make or an equivalent and you want version control.
Saying to do it the old fashioned way and not use an IDE is like telling me to do source control the old fashion way and name my files Woot.1, Woot.1.2, Woot.2.0 and keep a separate metadata file where I annotate what the changes were. Well, I hope people see what I am saying here. To me, using an IDE to handle something like building a project is no different than using a command line compiler that has dependency checking and recompiles source file dependencies.
I'm really quite surprised that people are so passionate on both sides of this issue. Pretty much as I see it, what I really want students to learn as fast as possible is how to think abstractly about a problem in terms of objects or procedures or functions (depending on the type of language), and then begin to delve into the interesting aspects of code evolutions (refactoring) and testing. If an IDE gets people to that point faster, than use it. If at some point they really need to do something without an IDE (I've never been in this situation in the real world--only in the artificial world of a class where it was enforced that you not use all the tools at your disposal), you can learn that.
A smart and capable student can learn to do basic things that an IDE does quite rapidly. But what a lot of students absolutely fail to learn coming out of school is how to leverage the hell out of whatever existing tools already exist to avoid reinventing the wheel.
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.
AccountKiller
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 ...
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.
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.
Python has an excellent interactive mode. For python, I'd recommend you teach that and let the students use whatever editor they please.
Look, you're going to be the instructor, so what you say goes. My advice would be to use an IDE like Eclipse, to take advantage of the benefits the interface has like checking to make sure they have the correct number of parentheses and/or braces and... um... stuff like being able to create, open, and save files in an environment in which they are familiar with.
Here's the thing... if you don't show them how to compile their programs with the IDE... they'll probably never figure it out. Let them use the editor for the programming and the command line for the compiling. That way, you get the best of both worlds, and avoid the headaches that will most assuredly come with trying to stay steadfastly with either one.
Besides, it's not like you're going to be teaching them to design swing interfaces... because if you are, you have no business teaching that class. They should learn to program first, and there's a whole lot of ground regarding design and data structures to cover before UIs should ever be mentioned.
Unless they have used them in the past, vi and emacs are not going to be intuitive for many of your students. There is a subset of humanity that thinks that vi is about the most aggravating purported text editor ever deployed. (Yes, there really are folks that would choose ed if ed and vi were the only two choices.) Emacs is more capable, but not more intuitive. Doesn't matter if the folks who dislike these editors are right or wrong. What matters is that you may need to work some of your students through enough of their problems with the text editor to get work done. That means that to some extent you would be teaching a course in vi or emacs, not a course in Python or Java. Is that really what you want to sign up for?
So you should go with an IDE? I don't know about that. The only Python IDE I have tried is IDLE and it runs so oddly under Windows that I quit using it after a couple of hours of struggling. (It acts like it saves files, but I'll be damned if I can figure out where it is putting them. Not where it says it is). I assume that it runs better under Unix, but I'm not sure that better is good enough. In any case, it certainly didn't make my life easier.
So it seems to me like you might want use whatever editor will cause you and the students the least grief. If you can teach the entire course with four line programs input from the console, maybe that's what you should do. If you need an editor, maybe you need to look for one that is as intuitive as possible -- joe, pico, mc from a Linux console. nedit or something similar if your students have a GUI available. Notepad if you are on Windows.
Maybe show them an IDE in the last class session just so they know that IDEs exist for Java and Python.
Just my thoughts. Not an expert and have just enough teaching experience to think that you have signed up for about as much job as any sane person would want to undertake.
You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey
Emacs _is_ a good IDE already. If you make use of the functions compile, next-error, gdb in connection with gcc -g, you get an integrated source code debugger, compiler, navigation of errors. Add to that etags and the tag-related commands, and you are quite set.
Good post.
Just one comment.
(I haven't atually finished learning python yet).
Hopefully, you never will.
Not a dig at Python (I think it's a great language), but rather just making the point that however long you use something, there's always room to improve, and learn new techniques and styles of working. Looking at other peoples' code can often be instructive (assuming they know what they're doing).
I agree with the parent (first without IDE than imo with Eclipse) for Java. But with Python I would teach without an IDE simply because an IDE does not have so much to offer for an dynamically typed language.
Dyn. typed languages are nice to teach in conjunction with other goodies like a the (in case of python) python-console (make shure to have readline in there for the [TAB] autocompletion funtionality).
Cies Breijs.
It is common practice these days to use an IDE for Java development, in part because Java exposes the compilation step and there are many things you have to deal with there. Java lacks an interpretive mode, so to test things quickly you often have to resort to features provided by the IDE. Python has no explicit compilation step, and has an excellent interpretive mode which can be used to diagnose problems and run only parts of a program a little at a time.
You should also make everyone have a lession in using a debugger, a profiler and a verifier as well. Learning that these tools exist early on is important. If these tools are provided via an IDE (which I believe is the case for Java but not so for Python) then that should also influence your decision.
I think that you should teach using emacs.
And IMO it is wrong to say that emacs is just an editor, it is rather a full fledged editor and with JDE mode, combined with senator, cedet, it has most of the facilities which other IDE's do.
In addition, it has modes for programming in many languages, be it python, ruby, lisp or haskell.
Best of all, it is programmable, and student can hack their way to their own settings and idiosyncracies.
Introduce your students to the Church of Emacs
Creativity uninhibited www.kreeti.com
IDEs are a brick wall to composition.
Just get a proper editor
As they kids would say : "IDEs are gay"
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
It's like learn math's, first you must do the roots by hand lete you'l never do that again. But you know howto.
In my experience (I took an engineering degree, so YMMV), it's largely a myth that students will learn more if you make the course more complicated. Rather, your students probably have a fixed amount of time that they will devote to your course, so you want to make the most efficient use of that time. If you make students spend more time learning how to use the text editor/IDE, then the students will either spend less time learning actual programming, or they'll spend less time on other courses.
I suggest that you let the students use whatever environment they want, but provide them with a suitable option that you're willing to support. Learning a new editor is easy if you're a good programmer, so concentrate your effort on making good programmers!
That said, any time somebody asks you a question, point them to the official specification, not the IDE, not a FAQ, and not some 3rd-party tutorial. Likewise, during exams, the official reference documentation should always be made available. Never encourage your students to pass off code that they aren't convinced is correct!
http://outcampaign.org/
On my college I've learned how to program both C and Java using nothing more than pencil and paper, we had no computers on front of us. Our classes consisted on the the teacher explaining to us a new topic and at the end of it we had to write a program on paper based on this new topic, this program was used to evaluate us. At the same time, we had a project which we had most of the semestre to complete outside classes, so we had to know how to use and editor and a compiler at least (I think we had a tutorial written somewhere that explained us how to use gcc). I learned how to program in these languages fine, and even today when I have to do a small program to test something or something like that, I don't use an IDE. btw, I hear that these days students at my college no longer learn through this method, they now use the Eclipse IDE in their classes.
Java has some decent IDEs and editors written in java. So start with e.g. jedit and show your students how to use javac and friends. When you later start teaching GUIs then use an IDE like netbeans or eclipse. By using jedit you can teach them how to use java in every-day life.
Are you really considering to teach those kids two things at one time? Getting them to understand programming will be hard enough as is. An IDE resembles something that's already familiar, which allows them to focus on the programming - instead of focussing on both VI and programming at the same time.
Part of the problem with java is that to write it the way Sun encourage you to write it you need to fuss around with beans (lots of typing to make accessors unless you have an IDE) and having a class per file and packages, etc. You spend ages setting things up right and refactoring is laborious using command line tools. I think the reason that IDEs are popular is to help come up with ways around these problems.
I despise IDEs because they never work quite right and I find myself fighting their intention to reformat my syntax or to ignore complains about imports I've made for classes I haven't yet imported. Many also lock you in to using their platform.
When I write java I tend to cram everything into a single Application class until I've stablised my approach to the problem. That's a RAD approach. If you want to do things the Sun way then you need to design things on paper first and then write it once you know exactly what you're doing.
IMO, if students are studying CS then they should get a grasp of unix early on, and being useful with one of the cardinal text editors is part of that experience. There's just no need for IDEs and it's bad to lock students into ways of working that they'll later need to break out of.
Believe with me, my saplings.
I work in a small Finnish mobile games dev company, and curse that IDE! Most of the guys have never seen a makefile. All they can do is click the icons in Eclipse, and mod the ant files a little. All their coding is Java/XML. Objects. Our tehcnical lead insists on having a object oriented design with tens of classes. Image how much that takes space when LO END J2ME handsets have JAR limit of 64KBs...
:)
Force the students to code asm, C, C++, Fortran, Basic... Not just Java with an IDE. And somehow, force the students to code on their free time. Force them to like about what they are doing. And force them to learn about things. Like about learning.
You know, IDEs do not mandate usage of RAD, usage of bazillion wizards etc. Aside from RAD, the real advantages of an IDE shine when your project spans multiple large source files. The IDE has knowledge about the files the projects consists of (at least, there is a list of all files for quick access, something I REALLY miss in vim for example). Going further, since IDEs know this list of files, they can apply refactoring properly, which is incredibly useful. (Refactoring is something I miss in Visual C++.) Autogeneration of the build system files is another benefit of using an IDE (although I recommend to stay away from IDE-autogenerated autotools stuff; then again, I generally stay away from them).
I prefer an editor for small stuff, like a helper application which consists of only one or two files. An IDE is overkill there. And yes, for learning how compiling & linking works, using an editor and a makefile is wise. (At least it helps later when linker errors appear, which is quite hand when the people don't know what a linker does.) But for bigger things, I prefer an IDE.
This sig does not contain any SCO code.
Some languages should be taught with an IDE, some with a text editor (in most cases, letting the students each select any text editor they like, _even_ if they pick Notepad, because it just doesn't matter for purposes of learning the language, although you should mention in passing at least once that there are much better editors available), and for some languages you can really go either way, depending on what your goals are for the course. Every student should at some point have to take languages taught with an IDE and languages taught with a text editor.
C++ is an example of a language that should be taught with an IDE. Among other things, the documentation features of an IDE are really necessary. Even more obviously, trying to teach Visual Basic without the IDE would be ridiculous and pointless.
Perl is an example of a language that should be taught using text editors, letting the students pick whatever text editors they want. Teaching Perl with an IDE would be like teaching algebra with pottery wheels -- it would just get in the way.
Lisp is a special case and should be taught with Emacs specifically, both because there are features you just have to have (not least, grouping-symbol matching) and because Emacs is customized using a dialect of lisp. Also, if you're teaching lisp, it's too good an opportunity to pass up to slip Emacs in there, so that the students are exposed to that.
I can't tell you which category Java belongs in, because I never studied Java, but I can tell you that you should set aside the advice of anyone who bases his answer on experience learning or teaching other languages with or without an IDE, and focus on the answers given by people whose experience is with Java, because this is a question that has to be answered on a per-language basis.
Cut that out, or I will ship you to Norilsk in a box.
How about Smalltalk?
They can learn about makefiles, and text editors later on when they have a general grasp of the language. Personally I see no reason that anyone should have vi or emacs inflicted on them ever. While they're handy for people who live in the shell, they are masochistic environments and there are countless numbers of very good, intuitive GUI-based editors.
I used to use jed (a micro emacs) all the time in XP for quick hacking, but since I discovered Notepad++, I really don't see much need for remembering a bunch of crappy keystrokes. Jed is great and all, but it is a pain to configure (and emacs is a nightmare), and when I just want to edit something I really don't want to be sidetracked trying to convince the POS to indent with 4 spaces not tabs when it takes 2 seconds to do it in other editors. Notepad++ does everything I need of an editor and has useful features like tabbed views and syntax highlighting. For more in depth hacking I use the IDE provided with the language which for me means Developer Studio for .NET or C++, or Eclipse for Java, xml, wsdl or html editting.
Makefiles are an interesting exercise later on after the basics have been learnt, but I'd argue that makefiles are not important until your programs reach a point that they should be split over multiple files. Besides which, makefiles have been supplanted with ant / nant. Unless the language in question is C or C++, there is little reason to be using make.
It depends on what they're learning programming for.
If they're actually going to be writing code for a living then starting with the basics - ie a text editor and command line tools - will give them a much better working understanding of the language and programming in general. Introducing them to an IDE later on will teach them how to use it to increase the speed of their development; larger projects are easier to work on when you have a decent IDE to hold it all together and the wizards can be a god-send when you actually understand the theory behind the code it produces. With the good grounding they'll also be able to see when the automaticly generated code is crap and it's better to do it yourself.
If, on the other hand, they're just learning for course credit and having another string for their bow, sod it and start with the IDE because they probably don't need a really good grounding in programming; knowing how to produce functional, if not polished, code quickly is probably more important to them.
Yeah, I had a sig once; I got bored of it.
When code I use whatever I want and my employee only cares that the resulting code works (if he cares about my tools I quit; I've already did it when they tried to force me to use some tools).
Why don't you do it yourself ?
Teach the code, test the code, don't mind how they did it ?
I would give a short intro and if they don't know any editor at all I would show how to use a simple editor (not vi neither emacs, something graphical and easy to use like kwrite or gedit or for the console, nano or j-something); but tell them that they are free to use whatever they want.
Some may feel motivated to search for better alternatives and that search will be educational in itself. They are likely to tell each other about different alternatives and argue whether emacs is better than vim... that will be educational in itself; it happens in the real world; let it happen in the classroom.
Pupeno
I had to use scsi when I was a kid. if it was good enough for us when we were kids, it should be good enough for them now!
--
"It is now safe to switch off your computer."
Although in general, I agree with you, I think that an IDE that allows the student to step through a programme and see where a mistake has been made, and follow values to see how they are changed, is an invaluable training aid.
It really depends entirely on the course. When I taught at college I used an IDE but when I was teaching post-grads I did not as I was teaching concepts rather than training them to programme. The post-grads were big enough to go and use whatever they wanted when they walked away and got on with their projects.
I love stacking my barbecues in the shed at the end of summer - you can't beat a bit of grill on grill action.
This is IMO _the_ tool to learn the language quickly. Test small pieces of code there, paste them together later. Teach them how to use the built-in niceties like doc(), dir(), ..
I second this. However, what I haven't seen being mentioned is the importance of seperating your GUI and implementation. Most people I know switch to an IDE the moment they want to do GUI stuff: simply for the GUI designer. However, when you follow the rule of seperating your implementation and interface you won't need to use one:
For Python: work code only, no IDE. Then if needed you could extend it with GUI programming with wxGlade or something similar. Keep telling them, they should be seperating their implementation and GUI and that a wel written class or engine can be put behind any gui they want.
For Java: work with code only and maybe some templates WITH propper comments and explenation. Then you might use a IDE like Eclipse but teaching with an IDE, mostly, turns the art of coding into the bore of clicking.
Coding is not about finding the right button on the IDE but about knowing which lines will trasnform your data into your awnser.
I've always been a good coder. This has made my degree (i just graduated :D :D :D) quite boring in almost every respect.
:( Its good :(. Netbeans and Ecclipse are overly complicated. I dont know where to start!
I dont think I learned anything. Most of my friend have never programmed before - or those that did used VB or called HTML a programming language. Scriptkiddies at the least.
Both the scripkiddies and the never-before programmers had the same thing in common - they did know how to learn. They didnt know how to use help or documentation. Javadoc was mostly inaccessible unless it was generated. Refering to the online version was something they didnt think about - they wanted all the programs, skel code and teaching material in one place. Their mentality was that if it wasnt where their teacher put it, it wasnt right, too hard, and nothing something to invest time in. People like doing the bare minimum.
To teach java, my uni used BlueJ - http://www.bluej.org./ It's quite nice! It's an integrated "IDE" (text editor honstly) with a visual class generator/explorer/maker. It makes understanding object relationships and inheritance easy. People dont get bogged down with the other principals they're learning, such as commandlines, SQL and ER.
SQL annoyed the hell out of me because I knew it, and I knew how to do most things, it was the whole sqlplus command line experience on an unfamiliar terminal with poor codepage (charmap) support. I couldnt use backspace. It wasnt daunting to me, but it was to others. We all shared in common the annoyance that backspace wasnt going to work.
In the end I noticed that most of my friend didnt understand what they were being taught in BlueJ. BlueJ has a lot of documentation. It introduces concepts such as hiding and coupling strength really well - but its quite a lot to ask in terms of reading something you dont understand. I feel a commandline input at the time would have really annoyed people.
In the end most people didnt care about their introduction to Java and it serious stunted their work with ASML, C and their software engineering exercises. They didnt see the need to understand and take in what was there. Those that can program will wiz through the BlueJ material and go "oh yeh, that!" "of course" "duh, everyone knows that?"... I learned a few things such as guiding principals and terminology.
The second half of our introduction to Java was applet coding. Very simple applets. Applets are annoying simply because they're GUIs. Before we did linear least fit algorithms and quadratic solutions as our assements. Applets have layout managers and for people to understand other peoples screen sizes and resolutions, and why absolute positioning is bad, it take a lot of time. A simple input and process applet that exports to a javascript skel is a good idea here. You can combine the whole commandline editor progress - a bit of nano or notepad - with the uploading via commandline to a webserver.
The idea with splitting the programming and concepts up into BlueJ and commandline-applet thing was so we didnt get shocked when we saw the code to the applet. We knew the basics and what to expect. We built on what we knew.
Its important people understand different environments. One of the things I find hardest in any kind of programming is setting up an environment - i want to compile now!
Have everything in one location, all the evironment options setup and the skeleton source files availible. One zip file is all it takes.
Matt
My editor of choice is ConTEXT. My IDE is VS
In amateur radio the old timers still insist that Morse code should be required of beginners. In a time when you can run your worldwide packet radio communications from a laptop while you sip a latte at Starbucks or connect through an orbiting satellite, oldsters still insist on new arrivals learning dots and dashes as if it were 1930. True, they want the requirement to be reduced to 5 WPM instead of 13, but, still, it is the requirement of an ancient skill that is no longer needed. It's more like a fraternity initiation than a practical need. It is an impediment to learning about what counts in amateur radio today.
Likewise, teachers who insist on today's programming students learning to program using the command line, like they did in the 1980s, are merely taking great enjoyment in torturing their students in order to extend the life span of their own rapidly obsolescing skill base. Wrestling with the computer is not programming. Programming is solving programming problems using a particular programming language, not spending hours figuring out which switch to use to correctly compile your pgm on this or that particular machine using who knows what compiler.
Today there are many powerful--even free--advanced tools to help students. IDEs like Dev-C++ and MPLAB and Eclipse make the underlying complexities disappear and correctly so. Compiler development is a specialty and programmers don't really need to understand what happens at that level.
Oldsters, stop torturing your students to extend the life of your rapidly obsolescing skill base. Keep up with and accept change. You don't need to learn how to make a flint axe before you learn how to drive.
E Proelio Veritas.
I'm currently a CS Senior and this semester is actually the first I've ever had to use an IDE (C# elective, due to a lack of other options over the summer). Frankly, I've yet to see a substantial advantage to using it, and some of the features actually bug the hell out of me. I'd far prefer to use emacs any day of the week. I think that in our department there are only about half a dozen undergrads who regularly work in an IDE, and I'd say that, while they're probably no less skilled than the rest of us, they're slower, and far less flexible in terms of what they can work with (as in, without their IDEs they tend to be unable to work, which leaves them helpless when the Windows machines start acting up.)
So to be direct, I say especially if these people are CS majors, go without the IDE.
Personnaly, whilst learning to program (self taught, so having a teacher maybe different on this matter) I always found that an IDE simply bogged me down. I couldn't find buttons, the syntax completion often drove me up the wall.
I do not know, having a teacher there to say 'this button does this' may sove this problem, however, it may not.
Personally: no IDE.
When I was learning OO/Java at uni, I noticed that most of my learner comrades, and indeed myself, would get caught out by trivial errors more than anything; missing semi-colons, etc. This would go un-noticed until running a javac, at which point I'd be looking at the biggest & dirtiest error-list since I decided to install Linux for the first time; just for one semi-colon!
Of course, being new software engineering, I'd then spend the next 10 minutes looking at this bloody console output to decipher what was going on - completely distracting me from what I was actually trying to achieve.
Now I'm a full-time software engineer and I use a good IDE, the trivial tasks are taken care of - I just have to focus on what's important; writing good software.
throw new NoSignatureException();
IDE's are great for getting predictable things done quickly. Once you stray outside what the makers of the IDS predicted you would do they start to work against you.
Some also create truly awful code, the sort of stuff no-one learning a language should ever read lest they pick up some very bad habbits.
So I'd say, teach them both. Emphasise that the IDE nice way to get simple stuff done quickly, but to really LEARN the language they have to use a texteditor and a commandline.
Ultimately I think the latter makes you a better, more productive programmer. Some people don't care about that though, all they want is a simple way to do simple things (this is not meant as an offense, we all only have 24-hours per day and only some of the things that interest us are worthy of some of that time). Fine, teach them the IDE.
Some people are rather confused about what the use for IDEs is.
It is not a tool so you could program without using your memory or to make programming easier
But college level students should avoid python it is an awfully designed language which overrides the law that programs should have a start and an end because of its crazy syntax.
Copyright infringement is "piracy" in the same way DRM is "consumer rape"
On the other hand, someone posted on the University's newsgroup a message about another IDE, BlueJ. To quote some of the professors:
This response was the reason they switched us to using DrJava, since BlueJ apparently uses a visual representation of classes and objects to aid understanding. I'm in favour of IDEs for the ease of use but I think it's important to be aware of the other methods, just like anything else. I don't clean my clothes using a mangle and washboard, but I appreciate that people did (do?) and it's a useful option for learning how to clean my clothes properly when I can't get access to a washing machine (or something..).
I'm hoping that, this year, we don't get a similar number thinking
they've learned a language called DrJava
Start without an IDE to show how it actually works. Once they can write stuff without an IDE. Show them the advantages, and disadvantages of an IDE.
If you learn without the IDE then using the IDE is easy. If you only learn via an IDE, say Brand X IDE, and the IDE changes or has a bug or your employer uses, and insists, on another then you have a problem.
IDEs are useful but if you 'need' one then you don't really know how to program. OK that might be flamebait, but it's true.
Bitter and proud of it.
If your teaching application design fundamentals and object oriented architecture, use the IDE- language specifics will just slow the students down.
If you're teaching coding techniques and overall programming efficiency and style, don't use the IDE. That's where knowledge of all the little language tricks is important and you want to force students to dig more into what the langauge has to offer to solve problems and write more efficient code.
How can anyone be "old school" with a subject that is only decades old. OF COUSE YOU SHOULD USE IDEs. The most valuable think you can teach is how to use the debugger. Writing good code is an engineering dicipline, and unlike something like civil engineering, the tools for developing software have not evolved over many millennia. You should also know that the tools that your students actually use over their careers will be sooooo much better than the tools you teach them to use. This is the observation of someone who both learned and taught comupter science 25 years ago, then went into the private sector. Because I didn't want to learn what HAD been done, but was more interested in WHERE things were going, I didn't worry too much about languages like COBOL. I knew systems like ORACLE were coming. Pascal was relatively new, and was worth learning, but there was this edgy language called C that we spent some time on in a language survey class. It seems like we used sharpened sticks to kill the elephant, but with my 2006 goggles on, I see that the elephant was a mouse. How did the elephant turn into a mouse? I GOT BETTER TOOLS!!! Better languages (C++, Ruby), better development environments, better debuggers, better utilities (Rails, STL, Php). Would you teach a civil engineer to build an interstate spagetti bowl interchange without using a transit? Computer Scientists are still building Rube Goldberg devices, is it a suprise to you that many poor programmers want the uninitiated to see programming as an art, not an engineering dicipline?
In my experience, it really helped me in the long run to not have IDEs in introductory programming classes. The first programming class I took (C/C++), we wrote our assignments in text editors, compiled them, and prayed that they would work. It really helped to get the common kinks out early, and even today I don't make the stupid simple mistakes because I learned to spot and get rid of them early on.
I think that a good class includes every option which has been mentioned in the threads. When looking at Java (my favorite) I think you should start by teaching them the basics of OO programming and the way Java works. You don't need computers for this. Then you can go on teaching basics like flow control, inheritance, dependencies, etc.
Then when its time to start looking at simple programs just get them to work these out using a plain text editor and make them compile the programs themselves. This will not only teach them the things under the hood but also teaches them the way things are layed out. For example; when you're creating a Java package which a few classes you really need to be on the commandline to get familiar with the used directory structure (say; org.slashdot.Header() and org.slashdot.Flood()):
org/slashdot/Header.java
org/slashdot/Flood.java
And after you have teached them all of this its time to slowly move on. At best you let the students create a basic API using the CLI tools and at a later stage when you've introduced the IDE bring out the API they previously made and link it into the IDE as a basis for a more advanced program. That would teach them that there really is no difference between CLI based programming and IDE where the language is concerned. It will also give them a good impression as to why you'd need standards.
I haven't had many good experiences using IDEs. Right now the only one I use is Quanta for web stuff, and even then I only use it for about 4 features. What I really can't stand are the ones that take half the control away from the user. One other thing - unless you've got fast PCs, avoid Java-based IDEs. Otherwise you'll be wasting most of the time waiting for the damn thing to load.
I've been teaching C++ and Java for seven years. I've found that the most effective method of introducing any language is to start back at the command line compiler and a text editor. The student should understand where the compiler components are and how to manually set paths to their working directory.
Later on, when they start to use an IDE, I have them go look through the builder generated code and try to find the code that they put in.
As an interesting and educational lab I've assigned them to create html builders. They really catch on to what a builder is when they write their own builder.
Another controversial subject is whether to start out teaching objects or leave them for latter. I usually leave them for latter so the student can focus on logical statements and flow control using simple primitives. Full understanding of objects comes latter when the student has programming capabilities to see why objects can help control program and data complexity.
...to let people use an IDE, but don't make the assignments focused on what the IDE can do (e.g. window/form layout), sending stuff from one window to the other with "onClick" functions, automated code wizards and so on. Create assignments that'll require them to create their own classes, their own functions, their own structure in the software. Honestly, I know about assembler and .obj files and the linker (plus uic and moc which are Qt-specific), but apart from fixing those wierdo bugs (oh, I deleted the redundant body but not the declaraction) I really don't care.
Good software comes from focusing on structure, which in my experience isn't what you learn in emacs/vi/notepad (hey, did I just manage to insult both of them?) because you get way too busy with syntax, spelling and indenting. IMO the best learning environment would be an IDE with a disabled compiler. The important part is really that you use your brain to program, not the compiler.
Live today, because you never know what tomorrow brings
For example, we teach a CS1/CS2 sequence of courses using an Objects-First curriciulum. In our CS1 course, students are exposed to a wide variety of "theory" (e.g. OO design and modelling, inheritance) and they are also exposed to language / syntax issues (e.g. loops, arrays, conditional execution).
I wrote a lab manual for our students to use, and the very first lab gives them information on the role of the compiler, including translating this stuff called "source code" into this stuff called "byte code" which is executed by this thing called the "virtual machine." In this lab, students write a stupid program (hello world, I think), and they compile it manually and run it. Then they do the same thing with an example that they are told contains errors, and they have to find the error and fix it (the class name doesn't match the class file name - Java *hates* this). This is the only lab where I have them using the command line. It teaches them that they *can* do it if they want; and that there isn't any magic behind the compiler.
The second lab uses the Eclipse IDE, and we redo the first lab (including trying to recreate the error). Then, the lab guides them through writing classes using Eclipse's code generation wizards (which, IMHO are *WAY* cool).
As the semester progresses, several new tips are introduced (e.g. after encapsulation is taught, and they've written 30 or 40 getX and setY methods, I teach them the generate getters / setters wizard).
The final plug for using an IDE isn't in the editor - its in the debugger. There are few things that appeal to the visual learners (that studies show a statistically significant portion of CS majors are) like watching code execute through the debugger. Students who are having a tough time building mental models of how this stuff works can actually see every instruction execute through the debugger - and it really helps.
I've been a CS professor for 6 years (at a "teaching" school), and have taught a wide swath of undergraduate and graduate, lower and upper division courses, and in all cases I've found that introducing students to apropriate tools helps them keep their attention on the important subject material (in the case of intro programming courses that is learning how to use the language and solve problems). Isn't this what its all about?
In the case of Java I would say not to use the IDE for a class. This is because the IDEs use features of Java that students are not ready to deal with on the first day of class, such as packages. I found when I taught Java that the students who used an IDE had a much harder time than students who just used something like Textpad.
I have been programming for about 18 years, so I had my fair share of plain text editor v. IDE.
If the IDE allows turning on and off enhanced features, then disable:
1. Intellisense or anything similar that suggests code for you.
2. Code generation wizards.
3. Anything that will rewrite whatever you just wrote.
4. Magic database tools from within the IDE that will "design" your database for you.
I find the following features helpful in quickly teaching a new language, so these should not be disabled:
1. Context-sensitive help
2. Pop-up method lists that work on hovering, not as you type.
3. Pop-up argument hint lists, to show you the arguments and data types the specific function wants.
4. Hooks to online version of docs.
The biggest trap in the IDE world is the tool v. language argument. Your students need to learn the language, not the damn tool. You are not an Eclipse or VS.net programmer, you are a Java, C# or whatever programmer.
The two worst things for a n00b (that really needs or wants to learn, not for the casual geek that is just screwing around) is that the intellisense-type auto completes and the wizards will not teach them why they are doing what they are doing. Once they know how the damn thing works, then it is OK because the tool helps them write faster code with less errors.
I spent the past four years or so sharing my time between classic ASP in a legacy app, and building its replacement app in PHP. Both through BBEdit. It was not a lot of fun. I am at a new job and we use asp.net here, a platform I had not used for the four years I worked at my previous job. It took me two days to get back up to speed.
Why?
Because I already knew asp.net programming, so all I had to do was to get re-familiarized with Visual Studio, which had gone up three versions since last I had used it. To make things interesting, my previous experience was with c#, and this shop uses mostly vb.net. It did not slow me down a bit.
We need to teach new programmers the old and sacred ways we used to be able to pick up arbitrary languages with nothing more than a good reference and a decent text editor. Or Emacs. I know plenty of people of reasonable intelligence, and not even driven psycho geeks, just your average slackers, that have picked up php, perl, ruby and python without much drama. Why? Because long ago somebody bothered to teach them how to program.
There are of course languages that are close to impossible to deal with without the proper IDE, but most these lessons still apply:
1. Make them write their own code.
2. Give them as much context-sensitive help as possible.
3. Make them write their own code.
Pedro
----
The Insomniac Coder
Using a traditional editor will have students gazing at incorrect language constructs while flipping back and forth between whatever they use for reference and the application text trying to spot the error. Repeat an error a few times and it becomes a habit, look at syntactically wrong code for a while and it becomes a recognized pattern. All counterproductive to actually learning the new language constructs. A syntax highlighting editor will let them see immediately when they enter something incorrectly and allow them to correct it before it forms a habit or becomes a recognized pattern. In general any tool that enhances the speed and accuracy of learning valid language constructs has to be a boon to the goals of your class. Teaching language X has little to do with developing logic skills. What it does give them in spades is adaptability to new languages. The more languages someone learns, the easier it is to learn a new one. When they get that first new job and the language is _, the more languages they learned in school, the more likely they are to already know _ or to be able to pick it up quickly. If you have secondary goals for the class, use those for determining whether an IDE would be a benefit or a detriment. Learning to code is a never ending process. Different people learn better in different ways. I would tend toward allowing options that will enhance each students ability to learn while minizing the requirements that they all learn a specific way (ie. with or without an IDE in this case). Give them a goal and expose them to tools and let them choose their own way, no one solution is ever perfect or the best.
A couple years back, I took an introductory C++ course at a public metropolitan university in the American Midwest. While there was no way the instructor of the course could determine what we were using to edit our code, in both the course and the optional lab we were first instructed to use our choice of either pico or vim, and were later encouraged to exclusively use vim.
By about halfway through the course, I was using Apple Xcode -- initially more or less as a text editor, but I did use it as a build environment with a proper project file and such for my honors project at the end, which spanned several files.
Teach them how to use editors like vi or emacs for small programs, then show them how to use IDEs for larger ones. Let them make informed decisions about their development environments.
COBOL for a CGI problem
I never did COBOL as a CGI program. But I did use Fortran 77 to make a game of Tic-Tac-Toe over the web. After that class the Fortran Professor took the Undergrad Internet programming class to understand what I did. Later one of the Stupid Professors (Who hires people who are Minoring Comp-Sci, to create code examples for her class, and grade her papers.) started teaching the class and unfortunately the students really lost out in that class. The never really understood what makes a Server Side Web Site. ("Content-type: text/html\n\n" as the header through standard output, if the form is type PUT then you get input in Standard input, if it is type GET then you need to check the Environmental Variable=QUERY_STRING, and print your HTML threw standard Out as well). But she was so stupid that she gave an assignment to research Server Side Web Programming languages. Where she assigned different languages some good for easy Web Development others which are not, and some that aren't a real programming language!, but a Database server. And now to bring it up the point of the topics of IDE or Not. I would say if you are able to explain the concepts of the languages and the students will be able to use these languages with an IDE and Not. Make sure they know why the language is the way it is more then how to do it their way.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
ant is one of the best reasons for using an IDE, the other being fast GUI Design.
Especially in a language like java that allows you to save and load XML files, without even taking a look at the concept of a parser.
As soon as you start using anything in java.util.* or an equivalent, advise an IDE and optionally give them a quick lesson in package management.
Last but not least: The programs should still be compiled and presented on your friendly neighborhood UNIX Server;-)
P.S.:
German native speaker abusing Oxford English, Grammar Trolls required.
*duck*
You can't teach first time learners effectively with notepad and command line compiling. They won't understand why you're doing it and what it's doing for them.
And that isn't effective teaching.
To teach effectively, you have to know WHAT you're teaching, WHY you're teaching it and HOW you're going to determine your students learned it (and to what extent they need to have learned it).
The WHY you're teaching something is the most important (IMO) because if you can't define (and convey) why something is important, then your students won't think it's important either. Trying to effectively teach someone WHY they need to know how a command line compiler works is going to be so incredibly difficult (remember, they have ZERO experience with programming, at best they've made an html web page) that they are going to turn off as far as learning goes and fall back to the "what do I need to survive this lesson mode" - which doesn't make for good learning.
The best way introduce people to programming (IMO again) is to start with an IDE and get right to the meat as quick as possible. IDE's take care of the management of code and they offer suggestions on syntax errors (IDE's like Eclipse for instance). There are less over-bearing IDE's, like BlueJ (http://www.bluej.org) made for beginners (fwiw I hate bluej, but whatever, some people like it).
After the student has seen some results and bought into to the "yes, I need to know more" mindset, then you can introduce the compilation process, make files / ant / whatever - but you need to be clear as to why you're doing it. If it's "just so you know", then guess what, students have plenty of "just so you know" information shoved at them everyday and for the most part they "just forget" it.
You know you're a geek if you've ever replied to a tagline.
I've been teaching intro Java at U. Penn. Here are my opinions:
* Students SHOULD learn to do everything "by hand", because IDEs
and languages will change out from under them.
* Using an IDE does NOT mean that they won't learn all the underlying
code; not all IDEs write code for you. I've been using BlueJ the
first semester and switching to Eclipse (without the GUI builder
plugin) the second semester. Next Fall I plan to start with Eclipse--
and, since I don't believe in teaching two things at once, teaching
Eclipse before really starting to teach Java.
* The problem with starting with a simple IDE (BlueJ) is that some
students resent having to switch to a "real" one later on.
* I try to teach what is important to my students, rather than trying
to "teach Java." In the quote real world unquote, not knowing how
to use a good IDE is an unnecessary handicap; but left to their
own devices, most people will stick with vi or Notepad forever.
Just my $0.02.
but hate wizards. and the GUI insertion tools (such as visual studio) can be to root of alot of bad/not-understood code. students should have a basic ide. i even resport to KDE's kate.
Power to the Penguin!
consider this: java and python are "high level" programming ... well ackward, but being ...
languages. "high level" programming languages are made so
they're easy to use ad give you many "pre-made" components,
like access to mouse, display maybe even soundcard. in high
level languages you don't have to implement these "libraries"
if you don't want to.
i think for high level languages with many pre-made libraries
it's completly and utterly necessary to use a IDE. you have the
tools, use them. the students will have treasure throve to dig
into for maybe something personal they want to do. (geee, writing
a dialog box or such from hand is
to draw it with a mouse and have the IDE spill ou the code, that's
neat.)obvious.
JAVA with it's crazy "blaH.bLaH.BlAh" syntax needs a IDE with syntax checker
anyway. (who's doing java anyway? python rulez)
if you're doing assembler it might be useless to use a IDE.
then again writing a GOOD IDE for assembler might be a formidable
task indeed >:)
so, high level programming languages = IDE YES.
low level = IDE probably useless
2 cents
As a programmer, I would suggest that you start without an IDE. It has been my experience that most IDE's provide a "suggested" way of doing things. If the outcome of the suggestions is not what the student intended, they will be hard pressed to determine why. Once the student has mastered the concepts of the language, then an IDE may make their life easer, but it may well make their life harder. Take, for example, an IDE that automagically allocates space for variables. If you have a memory leak (or the dreaded buffer overflow), finding a variable that *you* declared is much easier that finding the one (often incomprehensibly named) variable that your IDE defined to "make your life easier".
And ye shall know the truth, and the truth shall make you free.
John 8:32(King James Version)
You're supposed to be teaching programming. The less time you spend teaching them a new editor, the more time you spend tecaching them programming.
I remember we had an algortihms class that the instructor decided should be taught using PL-1* on an IBM 360 mainframe**. We spent the first 2 weeks learning JCL*** to get our code to compile, the next 4 weeks learning PL-1, and after the first half of the quarter had been wasted, we finally moved on to the subject he was supposed to be teaching us. Look at how useful all of that is now.
*PL-1 = Programming Language 1. Somebody had a burst of creativity that day.
**Mainframe = A room-filling computer that was used before there were minicomputers. They were not capable of playing Doom.
***JCL = Job Control Language. Like a shell script, only with an anal retentiveness for formatting that would make a Fortran compiler look like a pothead.
The only good debuggers I've used were part of IDEs. I don't care what linux geeks say - if they'd get past their "Micro$oft is teh satan!!1!" attitude, they'd discover how much they're missing out on (the Visual Studio debugger) when they use stuff like gdb/ddd. If you want your students to grow up using debuggers, give them an IDE. If you're ok with them deciding printf-debugging (i.e. printf's everywhere) is better than figuring out how to use gdb, well, have them use independent tools.
My server
Using an IDE doesn't tie you to a specific technology has had been wrongly said here. Walmart.com, for example, on the server-side, is running Java. Developers have the choice to use the OS/IDE they want: Eclipse, IntelliJ IDEA or whatever they think fits.
I've always got at least IntelliJ IDEA (using an emacs plugin) and XEmacs opened simultaneously. Switching from one to the other to work on a same file is a matter of three or four shortcuts (wether you do synchronization "by hand" or using some VCS). Last time I did it I needed to modify a codebase using lot's of System.out to use log4j: I'm not so familiar as to how to call Un*x commands from IntelliJ IDEA and easily see the result (and easily recover in case of mistakes, etc.). So a quick switch to XEmacs, opening the file, doing the mods, back to IDEA, re-synch and that's it (now there may be even faster way to do it, but in my case, it worked, and it was fast). I call fscking bullshit on the trolls saying that using an IDE tie you to the IDE.
I see the main benefits of modern IDEs in two areas: refactoring and static code analysis. Using a good IDE (IntelliJ IDEA) and good programming practice can greatly help when programming. I'm an old-schooler: I still use vi when there's no X Window System and I still use (X)Emacs a lot. But modern IDEs are just too powerfull: what is the point debugging a program just to find that you returned the wrong value inside a function/method when an IDE would have helped you spot that mistake instantly ("warning, variable xxx is assigned but never used"). Some cowboys here may say "newb!, I *never* do such dumb errors", but I call bullshit. I've been programming since 20+ years and still do these mistakes once in a while. But now it's spotted instantly: no need to manually compile, not even unit testing needed to spot that error and... Certainly not debugging. Instant IDE warning.
And there's better coming: check the Spec#/Specsharp demo (I'm not a MS fan boy at all, but this is impressive). Design by Contract added to C#. Then you're IDE does real-time analysis of your code and warns you if it thinks some contracts will be broken.
I use @NotNull extensively in Java (recognized in IDEA) and having message like "warning, variable xxx may be null" is convenient.
For the student, the question is: is there a point letting them write code with stupid mistakes that would have been detected instantly by a good IDE? Quite honestly I don't know, I'd say maybe. They have to understand how it works, how a debugger works, etc.
But for "experienced" programmers, I say no way.
And I call bullshit on the clueless fucktards saying it's either one or the other.
Because there are things in between. Students will need to be proficient with at least one text editor, be it Vi, Emacs, the one built into $IDE or something else.
So better tell them, they need to use a text editor, recommend the use of Vi or Emacs and offer some other editors. Those familiar with those ill-designed mouse-based editors on that other platform might chose NEdit in the end, some might even elect to slow down their progress by dragging in a heavyweight of an IDE, but it should be their choice.
BTW, I grew up with the Turbo Pascal IDE. Today I'm using Vim and the best IDE ever invented, which is Unix.
Cat is the way to go. As follows:
/* success */ ./a.out
$> cat > hello.c
#include <stdio.h>
int main (void) {
printf ("Hello World!\n");
return 0;
}
^d
$> gcc hello.c
$>
Wikileaks, no DNS
I think our field hasn't yet properly distinguished between the practice vs the theoretical. Other fields recognise the different subfields: medicine vs research, engineering vs science; but we do not.
Let's distinguish between programming (the art) and computation (the science). If you're teaching computationalists, starting with theory is neccessary. But if you're training programmers, I think you need to dive into computers and programs and IDEs. The latter is at least partly because of the kind of people that would like to become programmers; if I was crazy about pottery, took a course, and it was all about clays and history and there was never an opportunity to touch a potters' wheel, I think I'd drop the course, maybe even give up on the field, and buy a wheel and teach myself.
I think both programmers and computationalists need to learn common concepts, but for the most part you are teaching people with different interests and aptitudes, and after the first couple of years, expect the neccessary courses to diverge significantly. Doctors and neuroscientists do not take even vaguely the same courses after the first few years.
Lies about crimes
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.)
We know where leadership by an anti-intellectual "strongman" who scapegoats minorities and likes boisterous rallies goes
Sorry to reply myself, but I also meant to make an observation. I can still remember my college days, and I remember getting very frustrated over small problems, such as forgetting something on the classpath. I remember thinking I could read the theory myself, but I needed the professor for the problems that arose. In hindsight, perhaps the professor would have been best used for helping with elegant code. But do not leave the students to implement alone, unless you have a lab staffed with TAs on the weekend.
Lies about crimes
If you are trying to teach your students programming concepts, then an IDE is better. But if you are more concerned with them learning the language, I'd stay away from IDE's
Let them start out with punch cards and toggle switches...make them WORK to program. They can learn binary, hex, ASCII, and how computers work all at once.
Sigh...for the days of deugging assembly with just a pencil and paper, step by step...
After they pass that course, then they can use whatever the hell they want.
I've had a studnet argue with me that UNIX (circa '92) should have included graphics libraries. I argued that if he was a CS major he should have been able to program them himself.
I've had people in an Advanced UNIX Programming class that had only ever programmed in Turbo C++.
I knew of a CS PhD candidate who only ever used a Mac.
They will never learn the implications of their programming if they don't learn it the hard way.
rm
Sci-Fi Storm
What are you working on, a roll of masking tape? Or one of those old egyptian reed scrolls?
We've got random access paper now. It comes in sheets of various sizes and you can hop around all you want.
--MarkusQ
I personally use Vim and Joe to write C++ in linux. For windows, I am more relaxed with an IDE. I'll tell you though, tha writting the basis for an operating system kernel is best written without the distraction of "special features" as you will not be able to use most of them. I recommend you just use your best judgment, and what you would use to teach yourself. For me, that would be using Vim and Joe, writing custom makefiles (a VERY usefull skill) as well as mastering utilities such as automake and autoconf, etc. It all depends on your taste in the end though
Cheers, DH.
You think your sig is a problem, you should try mine. :)
Um, programs are just text files right? Many popular CS-languages have commandline compiler executables also, right? Let them choose.
I attribute much of this sloppy work to a growing dependency on the IDE and a fear of writing anything by hand. With advent of the modern IDE, with its fancy properties tabs and auto-magical code inserts, the "Drag-n-Drop generation" is becoming disconnected from their code. I'm constantly hearing "I'm afraid I might break the page," when asking for a minor change to layout or functionality. This tells me that the coder has no idea what makes the page look the way it does and that there is probably some scary stuff going on under the hood. (Unfortunately, company policy prevents me from calling the guy a wuss.)
To me, good code means that the programmer understands why it works and has the confidence to turn it upside down and shake it without fear of breaking it. I'm not against VI or syntax highlighting -- not even autocomplete or code snippets -- but I think 99% of the work should be taking place on the "Source" tab and that the "Design" tab is only there for the "Computers 101" class.
A girl I knew in college, a sophomore or junior, thought that a compiler worked by using a magic chip located on the computer's motherboard. She was concerned about being able to put Borland on her laptop and have it still work -- laptops of course lack the "compiler chip". She was a high-GPA, CS major.
I tell this story frequently as being illustrative of the current state of CS education.
N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
I tried to write some non-trivial Java code about three months ago after not programming in Java for a few years. I started out just using vim and my own makefile thinking that it shouldn't be so hard. It was a *mess*. I spent days just dorking with the environment variables to try to get the thing to compile. Once I got it to compile, it wouldn't run. Dorking around more got it to run, but I then couldn't compile anymore. I gave up and fired up Eclipse and let it handle all that crap for me so I could get down to business doing what I needed to do in the first place... writing the damn app itself.
And as for your subject line about "killing interest" in the course, you've got that backwards. It's much easier to get people involved and engaged with each other than with an IDE. For instance, divide them up into teams that have to write bits code which the other team has to check for bugs. Keep score. When they get good at this, make the challenge to be for the coders to slip security holes through. It gets interesting early and can stay interesting for a lifetime.
--MarkusQ
I teach introductory Java programming to students who have had about one semester of basic programming already (loops, basic arrays, stdout). In the previous course they use Textpad and compile "by hand". I start with a simple IDE that was designed specifically for teaching, it is DrJava, see http://www.drjava.org/ . It's open source and was developed at Rice University. There is also its cousin DrScheme, see http://www.drscheme.org/ , for teaching scheme. The main features of DrJava are: simple editor, "compile all" button, a simple debugger, and (very useful for teaching) a java "command line". The command line is cool because it allows interactive work. I don't have to recompile every little thing just to show them how simple things work. Later on in the course we switch to Eclipse.
In the end it is the language you want students to learn. Students should know that there are many opinions and options on how to program, i.e. with or without an IDE. As long as they learn to program, debug en test properly I don't really care about how. Maybe even let students choose.
O/T, but I really love your website.
Loading up your resume made me think of the Alien films.
It can get uglier than this -- third-party libraries, external utilities and other tools which are used daily for programming but which introduce non-programming-related issues in the process, such as deciding whether to use the vendor-provided packaged but sightly out of date version, or the compile-and-install yourself one, can easily add to a lot of variables that newbie programmers should not be burdened with. Issues like messing up /etc/ld.so.config so that your dynamic linker can find your just-recently-installed library, or messing with command line arguments in makefiles because they cannot install libraries and header files in the standard system locations -- this is the point where things start to look very blurry to students, and they just struggle to get their code running, most of the times making random changes to their setups which they read somewhere they found by googling on error messages.
Yes, most of this can be solved by having a competent system administrator that installs and tests every required library and external utility in standard locations, and makes sure every student system is setup the exact same way. But if you're not doing it properly, you end up supporting not only your students' programming troubles, you will also need to be able to debug their entire programming environments, which is not really the point.
That said, I do know that Python and Java can do a lot without external libraries, and thus the possibility of the previously described scenario develop is relatively minor. But that does not mean that your classes should be taught without any attention for these 'minor' details, because things might evolve in a different direction that what was originally intended during the course.
/usr/games/fortune: command not found
Speaking from my own experience, I would say that learning assembly and very low level languages first was quite helpful and eye opening as well as to a degree entertaining that sort of deep down control gives a bit of a better understanding about what's going on as you get more abstracted. It also gives a good appreciation for a concept which so many of my fellow students found hard to grasp (why write a function when you can just code two lines in and do it on the fly).
T Money
World Domination with a plastic spoon since 1984
If you are not going to use an IDE the only really useful choices are punch cards and writing the program out on paper first. I mean really if you are going to avoid an IDE it can only be because you are trying to get them to slow down and really think about what they are doing. Even EMACS is going to let them fall into the edit/compile quick loop problem. But it is going to do it without the helpful things that an IDE can do. If you want to have students really learn than you want a tool that can help teach and that is what a good IDE does. Why aren't you asking this question in a forum for teachers BTW? Something like the Advanced Placement Computer Science Teachers mailing list (http://lyris.collegeboard.com/cgi-bin/lyris.pl?en ter=ap-compsci) or the teacher forums at www.mainfunction.com for example?
Also, the lack of a need to get a product out of the door means that you can spend time on things that give a foundation. That educational requirements are different is an advantage. Which firms, for example, would spend three years teaching someone a maths degree? Yet those same firms would gladly hire a mathematician!
Wikileaks, no DNS
They aren't good programmers yet.
From the article: "Have had a semester of either VB or C++"
That implies that they're not just green but very green. I think one of his primary points is to find out what we think would be the best way to help them become "good programmers".
When I first learned C, I used Turbo C for dos. That is an IDE, but not much of one. I soon graduated to C++ (When it came out..) on unix using VI. That transition and the summary year programming without any kind of IDE really taught me the value of a good debugging IDE. Since that time, I've learned countless languages and used a smorgasboard of IDE's. But, learning to program without one left me with a strong appreciation for how valuable a tool they really are.
With that in mind, I have, on occasion, whipped out changes or written new features on a customer site without an IDE and am very glad that I learned to do that early on.
I would suggest that you start them out using a generic text editor. Since the first month or two of a programming class as usually not more complicated then Hello World programs. They'll struggle to debug them and struggle a bit with their syntax. Right about the time you can tell they're starting to get frustrated, switch to an IDE. Introduce it as a tool to help them. They'll very quickly learn it's value, but they'll still have some basic NON-ide debugging skills.
I'm not convinced of the value of assembly for this over just general experience with coding. Your particular example ("why write a function when you can just code two lines in and do it on the fly") isn't something that you learn in particular from assembly — I think the case here was that you simply had more coding experience than your classmates.
I think that most of the things you learn from assembly that you wouldn't learn from some high-level language concern micro-optimisation (which is usually detrimental if made too much of a coding concern) or memory management (which is not necessary in modern languages).
It is insane to let someone graduate that can't develop without an IDE. They are going to run into a situation where something won't link or the project file is damaged or whatever and need to know what really happens. They are going to need to work on a project that the wizards the IDE comes with don't provide a good start for at some point. Students MUST know how to program not just use an IDE.
That said it is equally insane for students to graduate without some familiarity with modern tools or the attitude that all those tools are bad. Most modern IDEs are really great tools and they have lots of boilerplate code and builtin framework stuffs that are great too. ave neat features for tracking things across modules and the like that are extreemly painful with just a text editor. In short they can help you be extreemly productive. They can also be a cruch and very limiting if you are trying to do anything new and different when all you know is the wizards.
Perhaps there should be a course or two in programing, where IDEs are not used and then a course or two in software development, where IDEs get used. Its a fine distinction I know but it could be useful in other aspects too. In school almost all of our assignments were completely independant. Which is fine for programing courses but in the real worls I work all the time on little pices of things where I can't change the interface with the other code and often don't even get to see the other code. I am just supposed to write a class that implents a list of methods I have been given and somebody else is gonna use it and they won't be allowed to chage it. This is the type of experience the software development course could provide.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
Nope, SCSI all the way!
Chris Mattern
An IDE, though useful, is pretty intuitive to learn. Command line tools and archaic text editors usually are not. I would be an advocate of teaching them the unintuitive first, and letting them pick up the intuitive on their own.
Our greatest enemy is neither a single man, nor is it a nation, it is, as it has always been, our own greed.
Rather than take a strong position about IDEs or old school, help them understand and see the value of both and recognize that their ability to choose and leverage tools is what will set them apart, not the tool itself. During their career, they will have a ton of changes to make and constantly learning. Getting zealous about tools now means they're destined to struggle through change.
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.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
Yes, they should be taught with an IDE. That IDE should be one of the following: Vim, emacs or NEdit.
The GeekNights podcast is going strong. Listen!
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.
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.
``Tension, apprehension & dissension have begun!'' - Duffy Wyg&, in Alfred Bester's _The Demolished Man_
I'd have to say yes. Since this is going to be an intro course there is a lot of ground to cover. Teaching good OO habits in java is complicated enough when you are dealing with students who have never seen the advantages it gives you over say C, I wouldn't want to use up at least one whole lecture, and probably a few lectures worth of Q&A/Debugging showing them how to deal with emacs or vi. Most IDEs will be very intuitive to anyone who has used a word processor, just with a few extra buttons at the top of the interface. Remember, this is only an intro course, if the students decide to become serious about programming you can point them to some online faqs about the great emacs vs. vi debate and the oreilly section of the bookstore.
Just some thoughts from someone with too much education who has seen professors crash and burn trying to teach three things at once.
There are nice IDE's. They can be very useful, especially if they know about the language's build-in libraries.
That said, Python, the language I'm more familiar with, I would say should be taught with an editor and a web-browser. (You can have the documentation pages local on your disk, but you need to be able to have several of them open at once, while you are looking up methods, techniques, etc. It's also useful to have a screen for grepping through the docs, to tell you which web page to pull up next. Of course you start simple, but that's the system you should be working towards.
Java...if you can find a GOOD IDE, one that doesn't add non-standard extensions to the language, then perhaps that's a good way to go. Do consider the expense. Many people swear by Eclipse, but that tends to promote SWT, which is not a standard library. Some people line IDEA, but that's expensive. Etc. I don't know of a good answer.
Of course, it also depends on just what level of course you are teaching. At the very basic level it makes more sense to go with a bare editor and a RESTRICTED number of libraries. A large part of learning any language is learning how to use the language libraries, but that's not where the emphasis should be at the start.
One final choice that you might consider: Dr Python. This is a Python IDE, and thus not what I'm recommending, but it's interesting anyway. I have it installed on my system even though I never use it (probably in homage to PLT, who did the Dr Scheme series). This IDE is based around wxPython, so it's also not exactly a standard library, and thus even more "not what I'm recommending". But it's available if you want an IDE for Python. It's license if GPL.
Then there's KDevelop, but to use that you pretty much need to be running KDE, and it wants your Python to be developed with the Qt toolkit. Definitely not my choice, even though I *am* running KDE. (I tend to develop with Kate + browsers. And I also use NEdit so that I can open additional windows for code or text files that I want to be able to see while I'm working on the programs that use them.)
I'm probably more opinionated than many, without any more reasons, but those are my opinions. I'm not claiming them as facts.
I think we've pushed this "anyone can grow up to be president" thing too far.
For the Python instruction, I suggest using IDLE. It's a simple IDE that comes with the language. Because of its simplicity, students won't become dependent on a particular fancy graphic system to keep track of their projects, but they'll still get the convenience of a console window and easy "compilation" of the programs.
Revive the Constitution.
If you have a lab with 1:1 on computers you may want to make a test of writing a simple script or without an IDE, to lety them see it can be done.
"Enjoy what you're doing! If it becomes drudgery, you're doing it wrong!" - Jim Butterfield
OF COURSE you should teach with an IDE. All you linux curmudgeons aren't being realistic about what programming is starting to look like today (and tomorrow). The CLi is dying anyway, and good riddance! The only reason for NOT using the features of an IDE (typesafety, runtime debugging, I mean jesus) are almost certainly ego (I save so much typing type, etc. BS is the common response from these crusty types).
/sarcasm off) and have gone on to be very sucessful with coding database architectures.
/rant off
As it may be obvious, I feel VERY strongly about the topic because when I was at Memphis State in the early 90s I was paying to take classes teaching CLi based Borland C, and getting PAID to code real estate apps for Macintoshes, by very nature a GUI. This particular problem, and the large smelly curmudgeonly professor that created it, just about led to my leaving computers altogether in frustration. Fortunately, I swtiched to English as a degree (abandoning the opportunity to pay to learn 80s technology in the 90s
Lemme say this plainly, I AM a coder. I spend 16-18 hours a day in front of a computer writing PACS systems for radiology and designing the way that the information that is generated by MRI modalities is going to find its way through data storage structures and then finally in front of a doctor. I also happen to have spent a large amount of time (about 6 years) coding against Solaris/Linux oracle in shells for utility apps, and I have to say that while Vi may be the king of the editors, even the primitiveness of Glade owns it.
An when I hire ppl for what are real work coding jobs, I want them to be able to use a STANDARD IDE, not just any one either. I don't have the time to try to teach standard topics like Sourcesafe or the VS IDE, so by all means PLEASE START TEACHING IT IN SCHOOLS.
--chitlenz
Imagination is the silver lining of Intelligence.
From my personal experience, most of the students who are going to succeed already have some experience with either CLI tools or an IDE before starting classes, and will be able to pick up new ones easily. The rest will probably drop out eventually, or they will graduate but be completely useless as programmers.
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.
I took a class in C++ this past semester and we used vi to do all of our programming. I found it quite difficult to up and switch from the good IDE's that do a lot of the error checking for you and also make stuff easier to read and debug. If you want to go down that path, I would have a good transitionary period where students are slowly taught to efficiently develop code in this manner.
I've had classes that required one method and classes that just cared about the end result. None of these tools are going to teach the data structures and methodoligies behind programming in general but a good ide will point out stupid syntax errors. I think the best approach was a Java class that I took that only cared about that the class files worked correctly on the official class server(working on your own computer did not count), were formatted according to class guidelines so the TAs could read and correct them more easily, and had well formed and informative comments. TAs held some sessions outside of class on how to use tools like IDE or Emacs/Vi. TAs would make recommendation on development enviroments or editors, but TAs/Faculty were not required to support any environment/tool beyond making sure the class server was accessable and had Java installed and working.
At UC Davis, the programming instructors had us use vim for about a quarter and a half, then taught us how to use eclipse(around the time that we were learning more advanced C++ topics) and told us that we could use either one for the rest of the assignments. I think this is good because I think vim is an invaluable tool to know, but I also feel that people who are going into the workforce or who are going to be doing larger projects than a quarter-long programming assignment may really be helped by having knowledge of an IDE. So, I guess my suggestion to you is, maybe teach both simultaneously. If you have demonstrations in class, maybe use vim sometimes and an IDE the other times. Or, if you use a chalkboard, just teach both and see what they use. This may not be an approach you want to take, which is understandable, but it worked for me.
I would avoid anything that complicates the process of learning. That means that text editors such as vi shouldn't be used and IDEs like Eclipse shouldn't be used. The learning curve can get in the way of the initial portions. Using a simple IDE or text editor really helps the student focus on the language itself. If I were teaching a Java course I would use Dr Java (I believe its provided by Rice University). Dr Java is about as simple as an IDE can get but the reason to use it is due to its interactions pane. Basically the interactions pane allows you to type a line of Java and hit enter and see what it does and all lines in a session are remembered so I could create a new String by typing: String test = "hello"; and then hit enter and the pane will tell me it was successful. Then I could type test.equals("goodbye"); and the pane would return false, so I'm learning how the String's methods work rather than having to put them in a class with System.out.println() statements. This was extremely valuable to me learning Java as you can write a new class and immediatley test it without writing a main method. You can also play in real time with things like ArraryLists or arrays and see how they function rather than spending long hours trying to figure these things out inside of your program. Also, it really requires little setup. There are a few downsides to Dr Java such as a few bugs but they are minor. However, I learned Java much more quickly than other friends who were stuck writing wrapper classes for their programs to test out simple functionality. If you're not using an IDE, I would have the students use Textpad as it supports Java and is simple. Perhaps as extra credit I would have students independently learn vi or Eclipse and demonstrate what they learned. BTW: Dr Java's interaction pane is available for Eclipse as a plugin and it really is great for Java developement.
In my experience having learned Java and C++ without IDE's was a professors subject.
My PhD teacher of advanced data structures said that we first need to know to understand how to build balanced binary trees, red-black trees, graphs and other structures without any library so we can implement the algorithms by ourselves.
The Standard Template Library of C++ or the java.util APIs in Java give you many implementations of data structures, search and ordering algorithms, if you use an IDE you can quickly make use of other libraries from packages.
But I think IDE's and these libraries should be used by small projects where it does not make diference if you use Mege sort or Quick sort in an array class. In large projects, all algorithms and data structures should be completely re-written, and it doesn't matter if you use an IDE or not, because you'll be using your own code.
I taught Java online for five years. I just taught the language and let them work out their own way of editing and compiling. It came out just fine. Different editors were used--they can teach themselves that stuff.
Now VB and C++ is you main problem. You will have to disabuse them of some misconceptions and some bad habits. But it's not quite as bad as it was back in the days of Pascal. I found the quickest learners were old COBOL programmers.
I teach a course in web design for non-majors. They have Dreamweaver and Vim available, with one page mini-tutorials on setting up and getting started with both available to them. Some of the students with good broadband broadband access to the lab from off campus use Dreamweaver, and the rest seem happy to use Vim. I provide a .vimrc that pretty much removes the overhead of switching between command and insert mode. I require them to format their source code so I can read it, which turns out to be easier for them to do consistently with Vim rather than Dreamweaver.
When teaching Java (instead of Javascript), the integrated debugger in Eclipse makes the IDE choice a no-brainer. There is nothing that prevents you from teaching basic principles of sw development when using an IDE. The Java language obscures so much of that (automatic compilation of referenced classes, linking at run-time, etc.) that that material has to be presented separately from the act of developing and testing the code anyway.
I don't mean to bring the 'calculator' issue up, but American students' math skills is quite laughable in eyes of international students, and many international students, including me contributed that to the unrestricted use of calculators. We were not allowed to use calculator in many situation when American students even can't find the answer with a calculator. It may not be directly associated with many advanced math theories in college/graduate level, but it surely help to build a habit of mathematically thinking from childhood. Being able to program with 'vi' and 'gcc' is a fundamental training a student should receive in the school. They can learn an IDE in 5 minutes, and then excel in a couple of days by themselves later.
The same reason most professional programmers use IDE's.
Because some aspects of code writing are easy to understand but are repetitive and time consuming. I'd rather a new student spend time understanding java.sql than typing get and set methods for classes.
Let's say that you have a project for writing a simple invoicing application. If a student had to type every get and set method for a Customer class, Order Class, InventoryItem, class etc the student could be typing for an hour just to build the basic data classes. Probably not time well spend for such an easy concept to understand. An IDE could do that for them in a few minutes which enables the student to spend more time on the useful programming of inserting/updating/retrieving and displaying these objects from the database.
However I totally agree with your point that the course should focus on the code, and not IDE tools. If a student completes a java course and can only read an xml file using an IDE's data wizard tool, and does not understand the underlying concepts then the teacher, and course curriculum have wasted the students' time.
Because engineers drill holes in the rock, fill it with explosives and blast it into wee little pebbles...hydraulics smydraulics! :) Then they subcontract to someone to haul it off...the fun^H^H^Hengineering part is over.
:P
I mean really, if you're dealing with rocks big enough to get in the way...you won't be moving them around as-is with puny construction equipment
When I was in high school, I was taught Pascal using a TRS-80 Model III. We had to design the program entirely on paper: first in a flowchart, then using pseudo-code and everyone's ideas were discussed in class. Then and only then were we unleashed to write code on the computer. Most of us preferred NOT to use the IDE (I can't even remember what Pascal compiler we used!), because it was simply faster to go in and type up our program, run the compiler, debug and rerun the compiler.
These days, I still use Pascal, but I do so in an IDE environment because there's more tools to help me out (such as a debugger, breakpoints, et al).
I personally suggest making your students learn programming on paper first, then having them learn the compiler. Perhaps in the final week(s) of your course, you could show the IDE to them and explain what it is.
I'm no professional programmer by any means, but those skills I learned have helped me in other areas in my life also.
Your email has been returned due to insufficent voltage.
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.
Learning how to write a good makefile in a text editor is a good way to get some basics of programming across to students early. I don't mean the thousand line wonders cranked out by automake (those are HORRIBLE), I mean a simple eligant Makefile that manages to express accuratly all of the dependancies.
Rule based programming with goal seeking. Not a bad concept.
Good answers for the entire posting. It's not your fault, but "trig through intro to calculus"
was still considered high school math 30 years ago.
Solid college science and engineering programs considered it remedial and non-credit.
For ten years there had already been entire 8th grade classes routinely learning Algebra,
and the next year -- still Junior High back then in many areas -- was Geometry.
So a senior who skipped math still had 2 years of "high school" Trig and intro to calculus.
Most importantly, what REAL college math have we missed by substituting baby math?
Physics isn't the only wasted course when the underlying language is not comprehended!
...at least initially. Let them learn the fundamentals of programming and the various compiler tricks and traps without an IDE. Once they mature enough, and have proven the understand the language(s) then you can introduce an IDE.
One of the better CS courses I ever had, involved "learning" a new language every 1-2 weeks. No IDEs, just vi and edlin. Of course, TurboPascal was the closest thing to an IDE back then.
IDEs frequently change over time. Fundamentals of programming tends to remain relatively stable.
I agree... thats why I also tried to learn Ant later in the year.
Its important to note, however, that you can't write a decent build.xml if you don't understand how the components of your JRE work (well, their interfaces anyaway).
Unfourtounatly my school system has a massive prohibition against downloading or installing anything, so I couldn't use Ant at school.
This isn't to say that I necessarily have anything against using a more basic text editor--using xemacs (or, rather, JEdit, because xemacs is painfully slow over SSH) for C coding has definitely helped me write tighter and above all more compiletime (and runtime) error-free code, and there's that angle to it, but for an intro course, where you're presumably trying to teach the fundamentals of logic over the nitty-gritty of syntax, having an IDE can, I think, be made into a convenience without having it become a crutch, so long as you're able to make clear that the actual coding is only part of a process of programming. Make it clear that the IDE is not the language itself, that a few basic steps will compile code whether it was written in vi, emacs, Notepad, or an IDE. Perhaps try mandating that "Hello, World!" be done in a basic text editor and then make some recommendations for other editing programs afterwards....
anyway, my $.02
One of the things that I found frustrating was that the University I attended had a preferred IDE for Java, which frankly is a bit shortsighted. Given that each individual has a unique learning style, it must be stressed that different programming methodologies espoused through IDEs appeal to individuals differently. I agree with you in that there should no longer be such a disconnect between the hardware and the programmer, and learning to use the basics is an important proving ground for any programmer worth their salt. I found it frustrating that I would need to submit a project file created in the IDE preferred by instructors (which wasn't free, nor open source) when programming in java is available in many different IDEs and flexibility and actually functioning code should have been more the focus (i.e. the write once run anywhere thing.) Students typically don't have the dollars needed to purchase the latest and greatest commercial IDEs and I hope that you're not intending to foist such a product on already strapped students.
if I claimed I was emperor just because some watery tart lobbed a scimitar at me they'd put me away!
Theres a big difference between a full-featured ide and a handy code editor with on-the-fly compilation, syntax colouring, bracket matching, automatic indention, refactoring tools and such. I would say go with Eclipse, in its basic form it does not attempt to write your code for you but it still makes you more productive.
Having said that, I wouldn't recommend Notepad either. Let them use a syntax highlighting editor (and don't force them to use a console-based editor like vi or emacs).
I learned a long time ago on a Apple 2+ Turtle BASIC. The then 'new' programing language of C from Greene Eta all. You Sir have two different things you are teaching, one is a 'scripting language'. For python a IDE is a judgement call- I suspect in the long run for a intro class the old war song of "making it fun and engaging" works well here-look at GPL'd projects-Portage from Gentoo for instance walk them through how it works or doesn't work for a intro class is a great way to make them want to learn best on their own. Java-in this case a mixture of the two. Why? It's such a unwieldy language that that sometimes the only way to 'see' the flow of your' program is using a simple 'ide'. I use itelij or bluej, then just textedit (jedit/BBEdit etc) to write the code. And again for a smester long project have the whole class work on how to impliment something 'cool'Mabie have them working on a game. It doesn't need to work in the end, and indeed that could be a fallback is if it doesn't work dedicate sometime about what went wrong.
When I took Java at my local University a few years ago, the professor provided us with a programmers' text editor, like Crimson Editor. I ended up doing my work in NetBeans because I was a lot more productive than with a "dumb" editor; so, the prof's strategy did not play out, at least in my case.
Since, I use a variety of IDE's, Visual Studio, Eclipse, PHP Designer for significant projects; and, I always have Crimson Editor close at hand for things that can be solved quicker than Visual Studio takes to load.
My recommendation to you is to give your students the option, letting them know that you are not going to spend class time answering questions about how to configure their IDE of choice.
WARNING: Smoking this sig may cause lowered IQ, insanity or short term memory loss. It is also really bad for your monit
"However, the student should be taught the 'manual' way first."
That was almost exactly what DaveAtFraud was saying. The introductory courses should not use an IDE. Those courses should expose the students to the underlying principles of the language (including the command line tools). Advanced courses should use an IDE since it will take care of all the little things that are not germane to (and will simply overshadow) what is being taught in the advanced course.
I agree entirely.
In an intro course, a large portion of the mistakes people make will be syntax errors (failing to match braces, forgetting semicolons, misspelling keywords, forgetting method return types, and so forth). Any editor with Java-specific syntax highlighting and automatic indentation will make these mistakes clear to the programmer. Generally, for new programmers doing suitable assignments in a high-level language, the student's intended program will be completely correct, and the frustrating debugging time will be spent trying to get the compiler and the programmer to agree on what the program actually is. It's only further along that students have programs that are what they intended, but are still buggy, where an IDE with semantic and runtime features will help them.
For an intro to course use the IDE. If the students want to become programmers then future courses can do without the IDE. For now let them use the most effective tools they can, especially as many taking the course will not be moving on to become programmers and will never use vi or emacs again.
I teach FreeBASIC, C++ and next year Java to highschool kids....lifting the hood(command line) and manually throttling (compiling from command line) is authentic and kids really resonate with it. Once they see how the car works, let them drive it from the cockpit. BTW, kids really like kate over kdevelop for some reason
I was going to write something very much like this, so I'll just agree.
Programming is very difficult beyond the very basics, and most people who do it for a living are able to do it, because they love it. Any less and eventually they will quit.
I think the job of someone teaching entry level programming is to get the students excited about what they can do with programming, and to introduce them to the basics with as little distractions as possible. Writing without an IDE, compiling, etc. are very important topics, but I think they should taught a little later when the students decide that they like programming enough to take a higher level class.
That being said, once you get into those higher level classes, students should be able to write code in Notepad/pico/vi/TextWrangler, and compile it using the command line,and debug it without a debugger; knowing the basics is very important, even if you mostly use an IDE in the future.
The problem is that you would teach or even think about writing software in python. Yuck!
let them use a text editor of their choice and explain the commandline compiler to them - if they use it like that or use an IDE is not of your concern then... you could point them to sites of free IDEs and tell them they might want to use an IDE, but you won't tell them how - they have to find out for their own, this is not part of this course
thats the way we do it at the RWTH-Aachen
The MAFIAA is a bunch of mindless jerks who will be the first up against the wall when the revolution comes
I'm not surprised this topic actually is at question in the *nix world.
This is exactly the reason why Linux wont make it at the desktop.
Command line interface is OLD SKOOL and unproductive.
Right now I program in VS2005 with the program *running* when I write code. Nothing beats it.
You say your studends did C++/VB, so they used Visual Studio, so they know what an IDE is.
... just to add the missing '}' and the missing ';' they need minutes, while in an IDE you baasically can't even make such mistakes. (without getting a notice, before even trying to compile)
To force them to use VI/EMACS and then to compile on the command line will simply piss them off. The turn around cycles (or the needed knowledge to work with multiple term windows) is simply to much to make this work fast, and thus its unenjoyable.
The point is: an IDE you can "use" without reading a manual, even if you then only use 1% of its options. In VI or EMACS you can't even save your open file without reading the manual.
Using a command line compiler means you have to "remember" the line numbers and the errors, result: they will fix one error, save again, leave VI again, compile again, and get new erros
Get them to use Eclipse and introcude some Refactoring as well, makes much more sense.
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
I am a comp sci student in a State University and through my experiences different people obviously prefer different environments. However the most important part really occurs before the student touches a keyboard. A computer language like any other has to be understood both syntactically and semantically, but even before that the logical concepts of language must be understood. Once the concepts are ingested by the students the next step is the implementation of the language in question whether it be C++, Java, ML , etc. This last semester I dove into java for the first time and I did it through a text editor and the javac compiler, and Everything I wrote I understand, where as a friend of mine in the class used NetBeans, a java IDE, and though he was able to produce code faster through its integrated API helper, I have retained more about the language without referring to the API for aid. I believe if the class is about learning JAVA a text editor may be better, but if it's a generic programming class, then an IDE may not be bad.
Found that while I was in college and never looked back (they started us on vi). And boy was I happy to see that in my terminal in OS X!
I do realize that it is too simple a program for anyone here.
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
what ass-backward school is offering programming classes using Visual Basic?
There were a handful of editors installed, and people used whatever they found useful. Personally, I made a bad choice and stuck with xedit (X11's equivalent of Windows' Nodepad).
The professors/assistants couldn't care less -- as long as I had a Makefile so they could build and run my code.
That said, you might want to make sure Idle or Eclipse or whatever is installed, and mention it in the intro to the exercises.
The problem is that most of them never seem to make that leap. The GUI seems to be an addictive crutch that prevents you from ever fully understanding what's going on behind it. Most people just think that the GUI is the computer, never realizing that it can function perfecly well and usefully without one. Microsoft doesn't help matters any by tying the GUI so closely to the OS, either. I've got about 16 windows build machines that I have to administer remotely and we have to perform some nasty business for remote administration (And logging into a remote GUI isn't what I consider "administration.") and making sure our builds complete successfully seeing as how just about every windows tool on the planet feels like it needs to pop up helpful dialogs asking you to click "OK". That's another story entirely, though...
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Hello There,
from my personal experience, an intro course requires a lot of time helping the students and hand-holding them through the difficulties of basic programming and the details of the language, tutoring on "what menu does what" is a waste of time and a detraction from where their attention should be focusing.
That said, the IDE is a convenience, and more advanced studentsw should not be prevented from getting ahead or learning more on the side. My approach is that you should give compiling instructions, preferibly in-terminal, that are IDE independent, as well as editor independent, and let the students free to use what they prefer, while using a reasonable variety of alternatives in-lecture - thus showing them the IDE, terminal+vi, etc options lead to the same result.
--- "I didn't think anyone would understand it" -Prof. Bob Muller
When there are restaurants out there, why do we cook? Because it can be fun, and because you can use your own recipe. The same applies to programming. Having some experience with raw programming and scripting, you can build your own automation tool, like nightly build. You have to admit the CLI-based programming has much much more flexibility.
When there are calculators, why do we learn to calculate by pencils and papers? Because there are times when no calculators are around, and because it makes no sense to find a calculator when you want to do some really simple task like dividing rent with your roommate. The same applies to programming. When a new language comes out without existing IDEs available, a previous experience of raw programming definitely has prepared you with fundamentals of compiling, linking, CLASSPATH/LD_LIBRARY_PATH/-I/-L, etc. When technology is changing, these things seem to remain relatively the same except for the names. Besides, it makes no sense to buy a Visual Studio license or download a hundred-MB eclipse just to write a C program of a few lines to calculate TAX.
I believe that IDEs can be a boost of productivity. But let's leave it for the trainers of industry, and focus on the raw, hard, but consistent part to the educators in colleges.
The problem with your argument is that CS2 is not a "high level" course. It's supposed to be second semester stuff. (I'd also argue that calculus isn't high level math.)
High level classes are items like Software Validation and Testing, Software Engineering and Software Integration classes. These go way beyond coding and problem solving with data structures.
Students should NOT use an IDE in the classic CS1-3 courses, especially 1 and 2. I teach programming and I get these students who have been brought up in the visual studio IDE and they are incapable of switching to anything different even in their senior year(s). They also don't know a damn thing about how compiling or linking occurs or even why they're needed. They can't look at a simple compiler error such as "unresolved symbol" and even begin to tell you what that means.
I'm thoroughly against using an IDE in the classes that teach basic programming. When the students get to classes that require project management skills, team coordination and code organization to be able to generate 5000+ line programs THEN they're ready for an IDE to help them. (I'm also against using Windows machines for the same reason that it attempts to hide the internals from the students.)
Learn the basic underlying tools first. Then allow them to wrap them in fancy packages.
I will never live for sake of another man, nor ask another man to live for mine.
Wow, this question was really throwing raw meat to Slashdotters. Goodness. This response is a little late but what the hey.
I would like to advocate for a minimal IDE. This keeps the widget sets from obscuring more conceptual issues, but isn't so nasty as the whole "ontogeny recapitulating phylogeny" 1970's command line approach.
The other question is what kind of I/O to use. I like using a little tiny non-oo library for simple UIs and another for rough 2-D graphics.
The point of this approach is to use something slick enough that it's fun, and yet is a good clear vehicle for conversations about concepts.
The strong man pushes the rock aside (where it starts a landslide and kills all the whos in whoville).
The wise man looks at the rock and realizes it may be there to teach him. So he learns and then goes his way.
Though I suppose I shouldn't complain - it does mean that the good students will have job openings in lots of other places where they won't have to work for this ass.
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.
When I took PASCAL and FORTRAN my teacher made us use pen and paper. All test were code from our heads onto paper and our grade was related to the number of syntax errors. I regard this teacher as the best I've ever had but...
After a few years, knowing how to use borland's turbo pascal ide actually became more important. As far as managers were concerned, the more familiar you were with it the more experience you had. Now days it is "the unspeakable tool" and Eclipse.
I think you should do both. Teach them with Eclipse but make them take tests with pen and paper.
Having to work for a living is the root of all evil.
By all means YES.
Having just completed my first year of university studying Computer Science, I have used nothing more than Notepad and Textpad for Java, whilst using LCC, vi and pico for C.
In all honesty, I've found these perfectly adequete. Using a full IDE would really be over the top for what was needed.
In an introductory class, it's probably best neither to use the command line, nor to use a professional IDE, but instead to use an IDE designed for teaching. Such IDEs tend to have support for things like language levels, interactive experimentation, and additional style warnings.
Many of them also do not contain support for GUI builders (or let you turn it off), which I consider an advantage in an introductory class.
For Java, there is DrJava and BlueJ, and for Python, you can get DrPython. The best of the bunch is, in my opinion, DrScheme.
As a CS student I would say definately give a list of approved IDE's. I know a lot of people who used Visual Studio to write C and C++ programs that were supposed to compile on the department's non-x86 Linux server. If your app wouldn't compile without errors you got a 0 for 25% of your semester grade. Needless to say gcc barfed out hundreds of errors despite the fact that VS compiled and ran the program fine. On a side note, the binaries VS generated were also about 10 to 20 times larger than those generated by gcc, not a big deal since the assignments required less than 1000 lines of code but interesting none the less.
Mod me down with all of your hatred, and your journey towards the dark side will be complete!
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.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
An IDE will be infinitely better than vi at showing them the internal interconnections of a program, and helping them (through syntax coloring) conceptualize the different parts of the language.
Teach low level tools like javac and ant seperately and second after they already grok the language.
Oh man, when I read the first line of your post I thought it said "They should have some great debuggers - they're in the business of writing tens of thousands of bugs per day." But then I noticed no one modded you as Flamebait or Troll. My eyes must be tired.
It's almost impossible to provide a meaningful answer for this without knowing who your students are, and where the class fits into the curriculum? (And where your community college is located.)
Almost every reply here has assumed that this is a computer-science class that's part of a regular computer-science curriculum. At most community colleges here in California, (where I teach), there's a big difference between the transfer-type CS classes (CS1, CS2, and CS3), and the community-development classes.
I teach an intro to Java course (CS1) where all the students hope to transfer to the UC or CSU system. For that class, I start them out in a text-editor, move them to BlueJ, and end the course using Eclipse. I also teach an intro to C# class where the students are an entirely different population. Once semester, I made the mistake of using the same basic (traditional) curriculum for the C# course, as I used for the Java course (as I think most of the posters here are suggesting.) By the midterm, I was down to five students.
When I switched to the IDE-focused, fill-in-the-blank, cookbook approach, I was able to keep most of the 40 students through the semester. Of course, I wasn't training them to be great programmers, (or really, programmers at all); but that's not what they were going to school for. If they were, then they'd probably be in the Computer-Science program to start with.
So, the real question is, who are your students, and what are you being asked to teach them?
This is something that I feel very strongly about. Having graduated recently within a class of 20 Computer Science students, I have discovered that very few actually know how to work with a compiler, text editor, make, or any other common development system (aside from an IDE). Since it was not mandatory to use anything but an IDE at the university from which we graduated, very few students gathered the experience needed to develop outside of a cozy IDE interface. I now work with several students who graduated with me. It has become a requirement that the software we have developed/are developing be built upon a Linux or Unix based system; the only standard development tools on these systems are make, gcc, and vi (sometimes Joe). Each one of these people are completely lost, and I am the one who gets to teach them how to use these tools. There are IDEs out there for *NIX systems, but none of these are standard; that is, some systems may exist without an IDE installed, and it becomes the responsibilty of the user to know how to use whatever the system has to offer. Basically, I am saying that there are situations where IDEs are not available, and a lot of people get stuck. IDEs are nice in that they offer easier-to-learn and convenient interfaces that help with development. They are not necessarily more powerful than the standard *NIX ways of developing software -- but it can be argued that they are easier to use. The trouble about IDEs is that they don't teach you about what is happening behind the scenes. They abstract away the interfaces to the compiler, and assume certain configurations that are not necessarily the most efficient or useful. A programmer should know how to use their compiler. They should know how it works, and what it is really doing. That is why I feel it is necessary to first teach them how to work without an IDE -- then, once they know what's going on there, let them use an IDE (as a lot of companies do use IDEs too). There. That's my rant.
its a lot easier to throw together something that sort of works and therefore manages to scrape a minimal passing mark with the help of a powerfull IDE than without.
Its a bit like graphic calculators in maths. The student can find out a graphs shape by getting thier calculator to brute force it rather than by actually thinking about its properties.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
I'd say only use an editor with syntax highlighting to help them learn better. Make sure it's pretty basic so they learn more and the IDE just helps them along. Type-o's can be a hard thing to spot for even experienced coders. That missing bracket or extra quote will stand out a lot nicer depending on the highlighting and help them see their simple mistakes quicker.
VI highlights a lot different languages, something like that to start off with wouldn't hurt I think. Easy to open, edit, and save a file. As they get better they can explore other options. Another good one is a basic version of jEdit with your languages highlight plugin installed. If your running them on Linux machines with KDE, Kate has some syntax highlighting too I believe.
~~ Behold the flying cow with a rail gun! ~~
The reason for selecting a higher level language is because it should be easier to code. Not harder. The linux community don't get it. GUI rox, console sux.
I would definitely not suggest the use of an IDE, in your situation. As I understand it, what you're trying to do is to teach software design. Everything which isn't about software design should be avoided. There's plenty to cover -- you just confuse the issue by bringing in this whole complicated IDE thing.
Besides, at a beginning programming level, a student might labor for hours over 100 lines of code. Only when you are fluent, might an IDE become a significant productivity enhancement (where you might blast out hundreds of lines of code a day).
Furthermore, I myself haven't found IDE's to be very useful. They really just get in the way. Better is to have total control of your development environment -- editing makefiles yourself. A syntax-knowledgeable editor is nice, as is a good shell, combined with a fast way to access API info. IDE's only let you work in a certain way -- conforming to a certain model. An IDE channels you into a very constrained way of thinking. That doesn't sound like a good idea for a CS student. You want them to explore the territory on foot. Later, they might get a car, so they can get from point A to point B faster (once they know where they're trying to go).
It comes down to a question of what the class is for. There often isn't much sense in teaching about a specific compiler/run time. Those kinds of things are usually dependent on what's already used at a workplace. So no matter what you teach, it will be wrong for someone. If you are teaching Java and Python, don't teach vi or emacs. Don't teach an IDE either. I would recommend using an IDE that is as simple as possible. Start with a generic understanding of what a compiler/run time does and how to use them, then get right to the code and teach that correctly. The code is what the class is about right?
BTW - If you really must use vi... go with vim instead to get the syntax highlighting.
You have to decide whether your real goal is to teach a complex editor such as emacs, project development using an IDE, or teach Java and Python. What your focus is will affect your choice of development tool. I taught an intro to programming course to high schoolers using Java a couple of years ago. Jedit is a nice editor with syntax highlighting for many languages, the menus are helpful because it takes time for students to learn the key combinations, and it allows for plug-ins which make it _almost_ an IDE for simple projects. You can pick a couple that actually make it easier for the students, not add to the complexity of learning a whole new environment. It was easier to learn than either vi/emacs or an IDE, and allowed me to focus more on the language. There are a couple of other text editors that you can do this with too.
In addition, most students used Jedit on Windows, a couple used it on Linux, one on OS X. Jedit was remarkably consistent between all three environments. Again, this reduced the time focused on editors/IDE's gave more time to the language.
It is much easier to teach these actions when you have a command-line where you must enter exactly one command for each step. GUI IDEs can be a little distracting and they tend to have a LOT of buttons on them which a new programmer might not need or understand. After students type cc -Wall -c myprog.c ; cc -o myprog myprog.o -lm ; ./myprog ; gdb ./myprog for a few projects you can then just give them a simple 1 line makefile or hand them a one page tutorial on how to use eclipse or whatever and let them figure that stuff out on their own. (I suppose you coulud show them in class, because adding files to projects, changing settings for libraries, etc can be kind of confusing in many IDEs).
I wouldn't have them use vi. Unless they already know vi (unlikely). You can do this from BBedit, xemacs, jedit, whatever.
“Common sense is not so common.” — Voltaire
In my experience of learning programming languages, as well as programming in general, in Scheme, C/C++, SML, Python, etc., the most useful feature of learning a programming language wasn't the IDE vs. editor question, it was whether or not there was an interactive interpreter for the language.
With Scheme, SML, Python, Mathematica, Prolog, etc., after learning a bit of syntax, you can sit at a computer and try the syntax out, work through your assumptions about the syntax, etc., giving the student a better idea of what is going on.
The other rub about writing actual software in these languages is documentation. I personally prefer to have documentation in any format similar to the Windows help file format; but that's generally because the documentation I tend to look at (Python and wxPython) have documentation that have convenient indices for modules/classes. I also prefer to have help exterior to the application in which I'm programming, but I understand the desireability of being able to have a tab for documentation viewable while programming.
So, to answer the bigger question: if the language has an interactive interpreter available, give students access to it (Python obviously does, as Java does if you look around). Be careful of offering editors with built-in interpreters, you don't want your students crashing their editor (test to see if the interpreter can recover from 'while 1: pass' or 'while (1);'). For writing software/assignments using standard libraries, make sure that documentation is easily accessable; external or internal to the application.
Once you've got an interpreter, documentation, and an editor that at least isn't braindead, you've got all of the essential tools for teaching a language to students.
Since this is a community college course, many of them may expect to do their assignments on their own personal computers. It's unlikely that they will have unix workstations or linux as an installed operating system on their private machines, unless this is a requirement of the program or the course.
Are they required to do their assignments on computers provided by the college? If not, then the most capable of them will want to do the assignments on their own machines.
It's entirely possible that you will get one or two students that have twice as much experience programming computers as you do and are there to burn corporate training credits and pick up some languages they are not familiar with. They will write the code for the assignments using their tools of choice, no matter how you tell them to do it.
IMHO, programming and building are two separate, but (obviously) very dependent subjects.
My personal feeling is that for the first introductory programming class or two the use of an IDE is perfectly reasonable. That said at some point (especially for CS, Comp E, IS, etc. majors) build technology needs to be stressed.
One option would be to teach the course in a hybrid fashion. Start off with an IDE and teach new programming concepts via the IDE. Introduce them to the products and by-product of compilation along the way minus the complexities of the underlying build system.
Once the students get a basic feel for the products by-product, file system, modularity, compilation, etc. then have them do a few assignments using MAKE and/or batch files. Ask a few questions about the build process on homework, quizzes and tests.
For most students it is neccessary to understand the build-process of a particular language. So it is a good idea to start with a really simple program without an IDE.
:-)
If they understand simple Java-classes and (a little) Ant-build-scripts you can introduce for instance Netbeans or Eclipse.
The nice thing about Eclipse is, that you can use it for Java and Python. But it lacks a GUI-builder (in the default package).
Also all depends on how many hours/lessons you have. At our university we implemented courses with 4 hours lecture time and 6 hours "homework". We start with some basic insights into Java and the basic concept of that language. Then the students try to implement a filemanager or something similar. At the end of the course they have a complete application.
In parallel to the program development, they have to document and discuss their work. To do so they have to work in groups (2-3 students).
As this is ther first language they learn at university, we are easy on them.
You should let them have either option. Although 90% of my jobs programming have had no command line access and I had to use a text editor (I use textpad still) to check things in and out of version control.
VERSION CONTROL! Make sure they understand the concept and get them to work on group projects with cvs or visual sourcesafe...
If you really want to help them you should give them open ended projects where they have to think and come up with their own designs and solutions.
Some other poster gave the advice to teach w/o computers and instead let the students write programs on paper. That way you can avoid that they fall into the trial and error loop with todays highly interactive systems (as opposed to programming with punch cards) and instead force them to think before they actually do something. Good advice!
:-) It's a one time chance to introduce these people a different approach to programming (as opposed to write -> compile -> test).
BUT: If you choose to go another route and actually use computers for the course, consider using ipython. Python itself gives you an interactive environment which is similiar to how Lisp was intended to use. ipython goes even further (check out the website for the features), is easy to use and comes in color!
I would say let the students use whatever text editor they want - I would recommend something that does syntax highlighting such as EditPlus. Using an IDE like eclipse is great for pros but it undercuts a learning student because it makes it too easy to code and you can't learn the libraries as well. When you type an object name and hit the period key, a context menu of available methods and properties come up. Makes it too easy! it also makes it too easy to package up jar files. When all you have to do is right click and select export you have no idea what is going on.
So - have them use a text editor to compose their java files and require them to use the Sun java command line compiler javac to compile their applications. You could even make them prove that they used command line by printing off their command line session and handing it in with their homework if you wanted.
And I'd recommend getting them familiar with the other java command line tools such as jar.
Towards the end of the semester you might want to introduce an IDE and have them use it in like one assignment to make a simple application. If you teach a more advanced course then I'd say let them use an IDE.
Conserve Oil, Recycle, Boycott Walmart
It's very simple Have them Use What they WANT.
Each person is a individual. They need to be taught how to use IDE's because that's what people are forced to use or choose to use based on their employer. Some people just simply much prefer IDE's while others are more productive and produce better code without the 'interference' from a IDE.
So teach them how to use all sorts of different tools. As a professor/teacher you should be fairly knowledgable in all of them. If you have some students that can't decide, just force them to use what you prefer so that you can help them out the most.
Some interesting items to take a look at:
Microsoft Vistual Studio (obviously)
Vim and Vim vs Vi (obviously) Lots of interesting stuff like ctags and whatnot.
Emacs (obviously)
SPE Python IDE.
http://stani.be/python/spe/blog/ (probably the most mature remaining Free Software IDE for python)
Kdevelop
Gnome Desktop and development environment. Maybe monodevelop
Eclispe Java-based IDE for a veriaty of languages.
Then version control systems. Popular and common open source items like cvs and svn as well as commercial items.
Just let them know what is going on. For small stuff use a text editor. For finals and big projects have them use what they want.
Grade them on completeness and code quality and then use that information to further refine your recommendations for the next crop of students.
Ok, I'm going to admit something embarrassing: After multiple courses in ANSI C, C++, Java from intro thru advance topics and networking, I still can't write my own complex or useful code. I don't really need to, because neither my job nor my hobbies directly rely upon it, but competent coding skills are sort of assumed in my role.
a tion approach. Everything was academic example, with no real world usage of IDEs, and certainly no explanation of what an IDE was doing under the covers. So I'm two steps removed from firing up a modern IDE to do something interesting. About every six months I decide I should finally figure out how it's done, but find no mention of it in the standards-based text I can find in print or online. When I look at advanced texts that discuss IDEs, it's assumed and not mentioned there either.
Why? Because no one ever showed me how to write my own libraries or deal with code that spans multiple files on a file system. I'm sort of a victim of the post-graduate every-class-is-a-one-week-powerdump-from-Sun-educ
So, yeah, I think both ought to be taught because the transition is key to doing *anything* useful. Sure, learn the theory first, but if you jump from theory to application without discussing approach, people like me get left wondering how we arrived.
If you want your students to learn an IDE, use one. If they should be learning just a languge, they shouldn't use one. But I wouldn't disallow use of IDEs either. Depends on how well they already know the IDE...
:P
Just my personal experience but when students are trying to learn a language and use an IDE at the same time (assuming they aren't already well versed with using the IDE), they tend to spend most of their time learning the IDE rather than the language itself.
I am old school as well as I started programming in mid-teens more than 20 years ago. So I tend to view programmers that can not or refuse to program WITHOUT an IDE as...well...they still have a lot more to learn.
Definantly should be done by the command line. It will probably be something most of them have not experienced anyway, so it will be a nice way to round off the course.
There are tons of editors on all platforms. Emacs and vi are the most popular on unix flavors, but hardly the only ones. Pico is the perfect example of an editor requiring no learning curve, so is notepad. Hardly the best tool for programming, but the students should grow out of them naturally (to either emacs, vi, jedit, ultraedit, eclipse, netbeans, or whatever they like).
Let them use what they want, they should figure out what env work the best for them.
Now, I admit that I'm a crank (I don't use an IDE to this day, but I'm also a theoretical physicist turned molecular biologist and no one's on my case about such things), but when I was teaching myself to program my C book had a little box in which it described how to compile a C program under unix. It took about a page. (The book was 'C: A Software Engineering Approach' which I appropriated from my father's bookshelf.)
I think this is a rational approach for an introductory course. Make sure the kids know that Word isn't a text editor, but besides that, just tell them the minimal about compiling a program. And then say no more about it. Personally, I was always furious when someone tried to force a set of tools on me.
Though if you want to avoid thirty undergraduates ergodically searching the phase space of programs, why not just take a set of initial conditions, and as part of the assignment demand a write up of all the steps leading from them to the output as well as a program implementing the technique. That's how I work out what I'm doing in practice before I ever write a line of code.
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.
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.
If the students want to use an IDE, let them. If they don't, let them. If they want to touch-type, if they want to hunt-and-peck, if they want to bring in a Dvorak keyboard, let them.
Show them how to invoke the compilers from the OS. Tell them what editors and IDEs you will give them help with in class, and give them a list of some other common and/or newbie environments that they might like but that you won't support.
(If you provide them starter code, be generous and give them a makefile too.)
Grade the final product -- the source files -- not the process.
I've taught a number of introductory programming courses at the junior college level. For my money, teach Java on Windows using DOS edit (or notepad) and use javac and java. Python comes with it's own native IDE, which you should use. The probmes lwith IDEs is that the student learns the interface, not the language. I've dealt with a lot of students after the fact, and they were whizes on the interface, but know very little about logic, pseudo code, variable scopes, and little things like that. If you want to teach them to program, don't use something that hinders learning to program. Serve it up raw. CC
Good grief, man! These are JUNIOR COLLEGE students! You need to seriously dial-down your expectations. You are clearly savvy and bright, but you cannot expect all (or even a majority) your students to be the same.
I do code reviews for a living. It requires finding the "abscence" of something, and looking for the data flows.
I want coders to stick to coding standards, and work on what's important: the code as a representation of the architecture. I don't want them thinking about the last 25 lines of code. I'm sure many are proficient at using vi and emacs (I am proficient at vi, for example), but it's about 25 years behind the times when it comes to efficiency, particularly when dealing with very large projects.
Builders are trained from apprecentices to masters, during which time they are taught to be familiar with all forms of tools, not just the power (ie "IDE") tools du jour. It's important for a builder to be familiar with a hand saw, you want them to be proficient and safe with a power saw.
Andrew van der Stock
Without then with.
IDE's make things easier when you already know what you are doing.
What part of the C or C++ language teaches you on how to click on add object?
Personally, I think it is good to teach any programming class using an IDE and command line for code compiles.
From my experiences... When I learned Java, we used BlueJ. We never did command line compiles, and as a result, we suffered when our IDE died due to a server issue. When I learned OOP, we were encouraged to use Visual Studio for our c++ code, however, we all found it easier to use gcc for some of our projects.
Now for my Python coding, I use Eclipse (IMHO, the best IDE for Java and Python using PyDev) for coding and command line for extended testing and deployment.
One of my professors covered both IDE and command line compilation in one lab... he simply made us do it. After that, it was never an issue.
Navicula hydraulica plena anguilarum est. Omnes castelli tuus nostri sunt. Ed elli avea del cul fatto trombetta.
First: are you teaching broad concepts or specific skills? And, if you are teaching broad concepts, are they concepts that are related to writing the program, or to compiling it? I say, use an IDE to teach them general programming techniques, so that they can get results fast and learn decisions and loops, and then take it away so that they can learn what they were actually doing.
...but is it art?
I was taught java using bluej, this had its ups and downs. Its a great way of teaching object oriented principals as its visual display of classes, inheritance and interdependancy can help to hammer in a lot of abstract principals to those not used to dealing with them. The downside is its not a very good ide, while it was good to learn with its not somthing id choose to write code with. It dosnt force people to use main methods when programing so frequently you'll see people writing code which compiles and runs under bluej but is useless within the real world.
I'd still recommend learning it the way i did, get the principals of programing down show them all the pretty things it does and warn them about its naughty features. Then when theyre comfortable with bluej get the writing code without it, command line tools and whatever text editor you like. Once they can write code in bluej, they can transfer their skills to notepad and javac. Once your used to writing code in both then you can work with anything handed to you, vi, emacs, jbuilder, eclipse all of it.
Just make sure they stop using bluej when you tell em to. At the end of my first year its frightening how many people havnt made the step away from it.
anyway have a look at bluej herebluej
In my experience, one of the easiest ways to learn a language is to learn some syntax, and then play around on an IDE with good code completion.
"You're welcome to use whatever editor or IDE to write the assigned programs - I don't care. I want to see your code, just your code, and nothing but your code.
I will say this - you can complete all my assignments using notepad or ed. It's an introductory course - if you can't manage all the files using a blisteringly simple text editor, then you're probably doing something terribly wrong.
If you want to take the time to learn a fancy IDE because it'll save you time in the future, more power to you. But I won't spend class time teaching you an IDE."
Heck... they should use a line editor. Those fancy full-screen editors are just too much dang coddling of those youngsters. If I had my way, they'd be punching cards, submitting them for batch processing, and waiting for their output the following day.
.out and what have you.
Make sure they don't use any cheats commonly available with these fancy SDK's like J2SDK, what with all those String constructs, and System class methods like
Code to the iron = assembly code. Heck, even that's cheating -- those assemblers. Ya never know if it's putting out the machine code exactly as you want it.
Emacs and Vi are both IDE's.
I have taught all over the country at a number of companies (perl/perl internals, C, C++, data structures, linux api, linux internals, etc). I have on occaision had to teach vc++. What I have observed is that those who use VC++ spend their time learning the tool and not the concepts or the language. If you keep it simple, then the student will be forced to learn what they need to learn.
I prefer the "u" in honour as it seems to be missing these days.
Check out www-csfy.cs.ualberta.ca to see one of the best-designed intro to Java courses in the world (University of Alberta - one of the world's most respected CS departments).. They teach from end-to-end using the Eclipse IDE (www.eclipse.org)..
The catch is that you need to teach the IDE in the OOP context.. IDE's (not glorified text-editors like VI and Emacs) are designed to help keep track of assets as well as the programming style.. If you teach the methods and algorythms using the IDE as a means rather than an ends to proper programming, you will spend less time on the details and more time on real skills like proper data design and efficient programming (unfortunately, something many of the self-taught philosophers you see in these forums lack)
Everyone who wants a real job needs to understand makefiles.
Or how to work on a command-line *nix system.
Everyone should know gdb command line basics too - how to get a stack trace, how to set conditional breakpoints, etc.
And using crap like the old[Microsoft 'AppWizard' that defines classes and methods for you is a disservice to students.
BUT to me there still is a huge productivity advantage to using a MSVC-style debugger. You will debug things that you might normally give up on or write printf()s for, and that ain't the right way...
Then again kids don't learn to debug anyway. Which is fine by me because it means it's easy for me to keep earning good coin.
Does it hurt to hear them lying? Was this the only world you had?
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.
With reasonable men I will reason; with humane men I will plead; but to tyrants I will give no quarter. -- William Lloyd
Start the semester without one. Make them use a text editor and do everything "the hard way". Then about half or 3/4 of the way through, introduce IDE's that have nice features for what you will be making them do.
...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
If a pion (n-) collides with a proton in the woods & noone is there to hear it, does lamdba decay into the source pa
Actually, I am a project manager in the "real business world".. I can tell you where the "craplets" come from, and it's not the programmers using the IDEs, it's those "pureists" that refuse to use the tools given to them.. Sure, their syntax is perfect and they know the language.. Hell, they might even know how to allocate memory to a program under MS-DOS without causing fragmentation with a nifty little assembly APP, but none of that makes a multi-million dollar project succeed - it is the programmers that can collaborate properly and follow a project plan as given to them from me.. (no, CVS and makefiles don't do this - logical project mangement does this - something better handled by an IDE than by a bunch of files thrown into a bunch of folders)..
The IDE assists in dealing with a project's assets properly as well as code-completion and debugging.. This way programmers can spend more time on learning algorythm efficiency, proper encapsulation techniques and modularization and, above all, efficient programming techniques.. There's no reason an IDE has to get in the way unless it is seen as a simple tool like a screwdriver, not a complex tool like a nuclear reactor.
Good catch. I'm going into e-learning(career). One more thing to watch for.
___
It's the end of my comment as I know it and I feel fine.
The question that needs to be answered first is: Are you a professor at a real university with a real computer science program, or are you teaching at a VoTech school.
If it is the latter, absolutely teach with the IDE, because showing proficiency with tools is a selling point with employers. After all, isn't it why they are accepting the institution's diploma as validation of competence?
If its the former, its irrelevant. You're supposed to be teaching concepts of computer science which impacts on the specifics of the course. Yes, a credible computer science program should put out people capable of developing code in an effective manner. But as I understand it, you're supposed to be educating students to be able to properly determine the best approach towards solving a computer resolvable problem, using the state of the art techniques. Not teaching students how to be the best code monkeys they can be for their employer. The tools used should be utterly irrelevant. You're teaching applied concepts and theory.
As an aside, a good academic program should have exposure to both IDE environments, and "non-automated" environments. But how that is structured should really be considered by the Dean. More important, I believe, is to teach an assembler class, or at least cover assembler in a systems class. Yes, its "painful", and almost all career programmers will never use it. But I think its a vehicle to insights as to how the computer really "thinks", and gives a better appreciate of what is possible and not possible with hardware. To remove THAT from the curriculum is a lot more damaging to an educated conception of the machine, than being spoiled by an IDE.
There is no America. There is no democracy. There is only IBM and AT&T and DuPont, Dow, General Electric, and Exxon
First, focus on what you are trying to teach, and let that guide your thoughts. Think about the context(s) the students will need to have.
Second, focus on what the students will need to know to get a good grade. In particular, if you are testing the build, deployment, and and execution of the code as part of the grade, describe to them the build, deployment, and testing environments.
Third, if you are going to allow the students to ask you questions about editors or IDE's, explain to them which ones you can support.
Having said all that, my best intructor taught us to "be one with the system". I learned a ton from him that I may not have picked up elsewhere. He encouraged us to use Emacs, and admitted that he had been a huge vi fan in the past, but he did not spend class time teaching these tools. These days, I use vi, emacs, and various IDE's depending on what I'm trying to accomplish.
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.
"It's here, but no one wants it." - The Sugar Speaker
Back when I was misguided enough to believe that staying at Uni, doing a PhD and teaching and researching is the right thing to do, I was part of a team that was doing research into just this topic over a period of about 5 years. This was back in the days where ides were just getting graphical, and at that time they provided a really good insight on the difference between cogntive overload and usefulness.
Here's what we found in point form.
1) There is a point where a student gets overloaded with too many features.
2) The ide should reinforce the concepts you want to teach
3) There should be visual access to tools
4) You should use the ide in your lectures and tutes all the time
5) Don't overload them with too much stuff.
So, my thought is, sure get an ide. But, try and find an ide that you can
switch some things off in. Find plugins that help you assist to teach the things you need to teach and pre-configure them (ie: code checkers, javadoc generators). Set up projects for things that are pre-configured and teach them about projects later. Disable things like debuggers etc to begin with.
One thing that people forget to do is to make mistakes in front of the audience. Then show the audience how to solve them. To that end, it is almost a good idea to go into your classes under-prepared and get everyone involved in the process of writing code. Then you have the reason to show people debuggers, find and replace, refactoring etc etc.
The ide is the tool - you need to make it work the way you want it to. A hammer does not do everything for a good reason - it becomes too unweildy.
In my next incarnation, I hope to come back as a code monkey.
Based on the title of the class (intro to Python and intro to Java) the class should use an IDE. This leads to the class sounding like an introduction to a language, not an introduction to programming. These are issues that should be discussed with the institution you will be teaching at. If it is an introduction to programming, then pass on the IDE and stick with a simple text editor for the first two or three weeks so the students understand the process that happens when they hit the run button in an IDE. After the first project, go back to using an IDE.
An IDE is not going to write the code for the student. They still have to figure out how to write the code properly. Since the class is an introductory class, an IDE would be very beneficial to a student new to a language trying to learn the syntax.
Overall, the question of using an IDE does not need to be asked. No projects in an introductory class should be large enough to have an IDE make a substantial difference. Generally, the student should be given smaller projects that build confidence in the language and their ability to write code. An IDE is only going to make it easier to look up functions and syntax to learn the language not write the code for them.
In the past five years I've had rubbish IDEs shoved down my throat and I've resented it. I go through the first lab sheet for each module, which introduces the IDE, and that's it. I've only ever used TextPad (www.textpad.com - notepad replacement including markup colouring) and Emacs for actual work in Java and C at uni, but they really did force us to use Visual Studio for C++.
Reasons I don't like IDEs:
- Take too long to load / use too much RAM
- Typically require so much faffing around that it takes *longer* to write a small program in an IDE than in a text editor.
- Text editors and compilers are more reliable i.e. crash less than IDEs.
- IDE = too much clicking... Mouse != fast.
- Different University staff have different preferences and experiences of IDEs, so you end up learning 5 different programs for the same task...
- Our University taught us to use a non-free IDE and locks the labs shut at 17.30. The IDE in question was something like $350 - talk about encouraging piracy.
My "boycott" attitude to IDEs at uni has saved me hassle, money, RAM, disk space and I am better able to reel off code from the top of my head (useful in exams and the workplace) than my peers.
"...it is the programmers that can collaborate properly and follow a project plan as given to them from me"
I agree with this. I am in much the same boat as you by the way, so I know where your coming from here.
"The IDE assists in dealing with a project's assets properly..."
This I have to disagree with. I know what your saying, and in theory I would like to agree, but I've seen cases where I was asked to essentially save a project that had become such a mess specifically because the IDE was allowed to go off and deal with the assets, while the original programmers didn't have a handle on what was going on. They couldn't even be sure each production build was going to work because they did not know the steps the IDE was doing (there were a number of instances of builds simply failing for no apparent reason that wound up being IDE config problems... not the IDE's fault per se, but had the programmers not been relying on the tool without understanding what it was doing, these problem wouldn't have happened).
One other problem I've found with most IDEs... well, more specifically, Java IDEs, since most of my work is in Java these days... they all seem to be painfully slow. Some are better than others of course (IDEA is *almost* usable to me)... but I've seen developer efficiency decrease because builds take minutes, simple things like right-clicking takes 2-3 seconds, menus take forever to load, etc. We are talking quite reasonable developer workstations here, so it isn't a hardware issue. Yes, you gain some efficiency with code completion and refactoring and all that good stuff, but I've found it gets balanced out, or close to it at least, by all the little delays, and certainly by all the problems I've seen.
But again, I'm not trying to convince you or anyone else that IDEs are evil or anything like that. I'm just pointing out some of the negative I've seen. I know there are tons of positives too, and plenty of people feel they are far more efficient with this IDE or that IDE, and I'm cool with that. I know what works best for me, and I don't mind sharing that. If something else works better for you, no problem. I tell all my developers that they can use whatever tools they want, so long as it all boils down to an Ant script that can be run on a "virgin" PC (i.e., just the JDK installed). As long as that is always true, I have no problem with them using ten different IDEs (we probably have 3-4 at the moment). I also require that the "core" project source not have anything IDE-specific in it. So, yes, they check out the core project and *then* check out whatever IDE-specific files they have to from a separate module, but it's a minor price to pay for everyone being able to collaborate together at maximum efficiency, where that efficiency is determined individual by individual, not by some corporate edict. This, in my opinion (and experience more importantly) leads to the best results.
If a pion (n-) collides with a proton in the woods & noone is there to hear it, does lamdba decay into the source pa
Some languages, like Java, students spend more time dealing with syntax instead of focusing on learning problem solving.
If the goals of the program is to teach fundamentalist, hardcore, empirical programmers then the ability to program with a text editor is great because they learn the basics of everything. If the goals of the program is to teach problem solving within programming languages, then dealing with the heavyweight, primitive tools distracts from the lessons.
In both cases, when students have learned their initial lessons, they should be the ones who make decisions on what works for them and what doesn't.
Lastly, arn't vi and emacs are IDEs.
Learning forges new neural synapses, but it doesn't _have to hurt.
;-) ). Anyway, we now use emotives and abbreviations (ie:IMHO) without even thinking about how our language is evolving. You see, that is what languages do -- they evolve.
Human languages shape our consciousness; describe our reality. If you learn a new language, you learn a new way of thinking that permanently alters you. I'm a firm believer in immersion, since you are forced to read && listen; write && respond. Think about the difference between communication in person and communicating with someone you've never met via email/internet relay chat/newsgroups. Things we take for granted like tone, facial expressions and body language do not apply and so one is forced to think carefully on the words chosen and the way the paragraph is constructed (well, maybe not so much in IRC
In the real worlde, languages are actually dying out in favour of ones more prevalent... like English. Meanwhile, flesh tries to convey ideas to silicon. Machine code translates our cognitive processes into bits that evolving silicon chips will understand... chips built with the aid of computers now in existence!
In this worlde, we have witnessed the birth and developement of several languages thus far -- and this is not the end. Within our lifetime it is highly probable that an entirely new language will come into being. What we need to learn is _how we learn. What needs to be taught is the concept that learning is never-ending.
Now to your question: IDE || {insert favourite txt editeur here}
IDEs are analogous to speaking in person -- they allow you to be sloppy, but they get the job done... however, they will not teach you how to think and veil the mechanics of how the language is being rendered into something inherently useful. If you are teaching CS students then you would do them a favour to teach what the IDE is doing. Don't waste your time and theirs teaching them to use a specific IDE, rather, let them choose their own. Focus ON the language... it's syntaxt... Compare its differences and similarities with other languages.
Start with an IDE then take it away. Give it back when they are able to meet a set of predefined criteria AS A CLASS (%90 of them anyway 'cause some people will _never get it and some just won't care). Instilling a sense of teamwork is vital since software is becoming too complex for a single person to write (well). Spend some time brainstorming (within groups) on rapid fire solutions to a simple problem using pseudocode. Homework for that session would be a handwritten (and on-your-honor untested) solution turned in individually. Show them solutions that work && solutions with flaws but let them peer review it, and let them explain _why it's wrong. Do not identify the authors. The person who got it wrong will have learned something without shame/ridicule. Since homework is a small percentage, everyone should try something bold at least once! Classic algorithms have their place but reward original thought. Instructors follow lesson plans but Teachers respond to the dynamics of the group. Good luck!
A bit of personal history here: At one time I thought that I couldn't do math. My Mom said "That's OK, some people just aren't wired for that." And so, until I read 'Tao of Physics' I never really questioned it. This was in my mid-twenties. When I returned to school ( a community college, which is why this question caught my attention) I learned algebra in as many different ways as possible. There was classroom instruction and video tapes in the library. Of course there was the book, but I also had to learn how to use MathCAD and an HP48GX calculator and somehow, I accidentally learned rudimentary FORTRAN. Now make no doubt about it: Math _is a language and it's syntaxt is paramount. During several courses with my teacher, I learned the following:
The calculator is just a tool -- do not believe it blindly as it is no substitute for thinking; Always perform a sanity check -- is this reasonable?
Translation follows::
The IDE is just a tool -- it is no substitute for thinking; Always perform a sanity check -- is it reasonable code for _all situations/ for _all input?
No idea...
Sig (appended to the end of comments I post, 54 chars)
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.
http://erichsieht.wordpress.com/category/english/
I definitely think they should all have an IDE.. I mean, they give you the ability to use your harddrives, your cdroms, and other specialty drives.. its a necessity for computing.. although, I'd recommend switching to SATA for your HD at some point in time..
*plays the Apogee theme song music*
One thing that seems to miss in this discussion, is the fact that programming languages are just a means to create software that actually does something. Assuming that you would like your students to find some practical value from you lessons, I would suggest trying to come up with a curriculum that supports just that. In my opinion, that would mean setting up a number of relevant excercises that create a challenging environment four your students to find out why and when Java and Python are good solutions for software development. These exercises could be used as a means to have your students discuss their various approaches to solving the given problems, so that they become aware of the pros and cons of their own solutions and those of others. In my opinion, learning a programming language means learning the concepts behind them - not just the syntax. For that, we have IDEs. The computer is your friend when it comes to following APIs, creating loop constructions and all that. However, how we choose to use the language to solve our software development challenges is up to us software developers. I suggest you focus your curriculum on supporting just that, and use every tool you can to help your students focusing on the actual concepts of software development and take the trivial, boring stuff out of their hands. If they choose to be professional software developers after they graduate, they will use IDEs anyway (or get fired ;) so they might as well do so from the start.
I wouldn't really worry if your students get to understand all about compilers, Java byte code, etc. I don't even know myself if the Java Virtual Machine I am currently using is an interpreter or a Just-In-Time compiler - and I have 10 years of Java software development experience. If my code is too slow I make it faster, that's all there is to it.
I'd first introduce them into using the command line tools so that they get a feel what an editor, compiler/interpreter is (and, oh yeah, how to set the CLASSPATH). This lets students relate more clearly how the development cycle works.
Afterwards I'd teach them that there has been some progress in software development, and that now we have powerful IDEs that integrate all these tools.
I don't think you can just rule out IDE or rule them in either. It depends on the class objectives, and the level of the students within it. For example My first programming class (well second anyways the first was supposed to be C++ in a borland IDE taught bya Civil Engineer who clearly didn't know much about the curriculum it was an easy A for me) was Ada. This was an excellent class because not only did it teach good fundamentals in a strongly typed language but it forced us to do some programming in a supervised laboratory environment. Now we did have access to emacs, but honestly I don't think we even took half advantage of the thing. The labs used Sparc workstations. The second class was a data structures class (Queues, lists, etc.) and that two was similarly structured. I felt I got a good idea of how these things worked. What irked me off though was after that first year the CS Department merched with the EE department and most of the EE machines in the computer lab were not that same environment. They had Visual Studio (whatever incarnation was out then) and I was never able to learn or take advantage of it back then. Thus most of us ended up writing in note pad ftping code to our accounts compiling through telnet and it was a pain. I think at some point you need to design courses to train people for work not for environments they will never touch. So I don't think every class should have access to an IDE but a lot of upper level ones should at least provide a means to take advantage of them or sufficient computers to do the work.
How about both ways?
Let me tell you about my college experience on this front. For reference, this would have been between fall 1989 and spring 1994, and I fully realise that a lot (GUI quality, for instance) has changed since then.
Different classes that I took in college used or didn't use IDEs based mostly on the professor's choice of platform. The fundamentals courses (which I aced becasue I'd been programming for almost a decade before I got to college) were all taught within an IDE. This was true for most of the courses where the platform of choice was DOS.
However, when taking courses where VMS, PR1MOS or *NIX was the platform of choice, there were no IDEs. We were shown how to use the different editors (vi, emacs, TPU), and how to use the debuggers, compilers and linkers and left to figure out what to do from there on our own. Tool choice, from that point on, was up to the student.
One interesting exception was the x86 assembly language programming course I took, where we did not use an IDE, despite working on a DOS platform. QEdit was the editor provided by the college IT guys, and we would then just feed the text files into tasm to get our object files, etc, just like working with a compiler on VMS/PR1MOS/*NIX.
Today, I mostly code without an IDE, but I have them available to me, and know how to use them if I need to see my code from a different angle. Generally, both emacs and vi do a good enough job of syntax highlighting and linting that problems are apparent before you try to compile.... at least in my experience.
www.wavefront-av.com
Well, you say the kids who will be in the class will have already completed a class in either VB or C++, right?
..
Those who took the VB class will have been taught to depend on an IDE.
Depending on whose C++ they were taught with, those kids will either already depend on an IDE, or not know what one is.
So, you'll need to be ready to convert kids whichever direction you go.
I have to agree with the early posters, though. The closer to the compiler the kids work, the more about the langauge (and computer languages as a group) the kids will learn.
I know taking the young men and women who have learned to work inside Microsoft's VB IDE and then teaching them to work with ForTran on a UNIX box has been frustrating me for several years at this point, because they expect the IDE to handle things for them, or they think that basic logic structures don't exist in ForTran because it isn't VB . .
The fewer service layers between the students and the OS, the more they HAVE to learn in order to make things work.
The big issue here, of course, will be providing partial credit for the projects that don't get finished.
Good luck!
if you have the time. If not, do it without. Then they'll now more about what is really going on. And when they get to the workplace, they can learn the IDE that's used at their place of business.
Coder's Stone: The programming language quick ref for iPad
Like editors, an IDE can be a very personal experience. Some people really like IDE's, some people don't. Some people like one IDE and not another. By teaching using an IDE, your going to hamper those who dislike/don't understand the IDE from learning the language. Just teach the language. Those students who want an IDE can learn it on their own. Those who want an editor with lots of macros will download them. Those who just want a text editor will use that. By teaching at the lowest common denominator, all students can learn as all of them will be able to go to that level.
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.
Debugging through prints? I haven't done much with java, but you do that with c++ sooner or later in your programming you'll come across a segfault, and it won't print some print lines that have been already executed. A debugger is important for tracking programming errors that cause a program to crash, all print statements will do is catch logic errors.
So with that out of the way, teach with something like vim 7, has tabs, split screens, folding, autocompletion (that will autocomplete from header files), visual block mode, substitutions, really quick copy paste between files, etc... So while deal with a complicated IDE when you have something more powerful in a much less resource intensive editor? Now if only vi could be embedded into firefox with an extension for writing comments on slashdot...
Teach them how to write software, let them write it with or without an IDE. Don't waste your time (and their's) teaching them IDE features. The code is what is importiant, not what they use to write it.
I teach C++ and a class called "Game programming and graphics" at my local community college. I've been doing software development for more than 30 years and have used every type of development environment there is. I have read debug info using a magnifier to inspect the color of individual pixels that were set by firmware as it booted up. Programmers will learn the tools required by the job at hand or they will be replaced. OTOH, when learning to program you want to reduce the distractions as much as possible. You want the students to spend their time programming, not worrying about the details of their development environment. For that reason I prefer to have students use an IDE. Hey, I use emacs and that is a pretty powerful IDE all by itself.
In my classes I have taken a very liberal approach to this question. I let the students decide for themselves whether to use an IDE or not and which IDE to use. I want them to use tools they are comfortable with so they spend their time programming. As a result of my policy I have had people in my classes using DeV-C++, the free versions of Visual C++ as well as the expensive versions all the way up to the pro version with an MSDN subscription, Emacs and make, and one fellow who used a nice looking IDE on the Mac. (So far about 85% of students are on Windows, 14% on Linux, and 1% on the Mac.)
The problem I run into is that every student expects me to help them with problems they run into with the IDE they have chosen to use. I get no end of complaints because I refuse to help students with problems with their IDEs. No teacher can be familiar with all the IDEs that are out there. It is a pain to try to keep up with just one or two. How are you going to help them with problems with Visual Studio Pro if you don't own a copy? How are you going to help with Emacs if you don't know it?
My suggestion to you is to pick a single cross platform development environment that you are used to and knowledgeable about and require that the students use that platform. It has to be cross platform because you are at a CC. The reality of community colleges is that a lot of your students are lucky to have a computer at all and they may not be able to get a different kind of computer or even a different version of an OS just for your class.
I'll make a couple of other suggestions, be prepared for nasty calls from parents who have already laid out $1500 dollars for VC++ Pro and to see students drop the class because of the tools you require them to use.
BTW, when you find that cross platform IDE? Let me know about it. I've been looking for a while now.
Stonewolf
Given that your class is one quarter, or one semester; You can either teach the best use of an IDE, or the fundamental syntax of the language. Of course, one could review what one was hired to do? Another argument is that IDE's come an go with the tide. Fundatmentals of software engineering are fairly persistant. Constructively speaking, maybe one should teach how to apply software engineering fundamentals using a given language syntax.
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"));
Without.
Flying is easy, just throw yourself at the ground and miss. -Douglas Adams
Try teaching them Java with NetBeans IDE. Works well on Ubuntu/Windows and is Free. I find no gain in NOT using an IDE. The more interested students can debug, refactor and analyze code better with such an IDE while others can get enjoy the syntax highlighting, code-inspect etc. Please don't put them on to Eclipse which is not an Integrated Java IDE by default.
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.
Speaking of quote, why did you shorten yours? The actual quote from Atlas Shrugged is, "I will never live my life for sake the of another man, nor ask another man to live his life for mine." Seems like it should fit.
Cheers,
Dave
They that can give up essential liberty to obtain a little temporary safety deserve neither safety nor liberty.
Ben
with features like code completion.
But debugging and color coding, I'm not so sure...
This argument reeks a little of a similar argument of the assembly programmer saying that higher level language programmers should learn what's under the hood. And this argument at one time was valid, but now seems a little insane. And I think the IDE argument is next to follow. Because I think languages are becoming inseperatable from their IDE, where one could go as far to say that the IDE is becoming part of the language.
Languages should be taught first, because it means that students will be able to do more. Then, later, teach them to use an IDE, because it will help them organize their projects and develop faster.
I learned Java with only Notepad, and I think it helped a lot - it forced me to really make sure I know what I'm doing, and to try and understand why the compiler was giving me certain errors. It also forced me to kind of learn to debug things on my own, either by working through routines on paper or by iterating through them in my head.
It's also good not having to learn to use an IDE - all you learn is pure coding. Which makes things a little more straight-forward.
Actually, I still don't use an IDE. Maybe if I'd try one I'd learn to like it. But I'm content with just using a text editor like KWrite that highlights certain keywords and understands certain Java commands, and can do things like collapsing subroutines to make things easier to read.
www.linuxpenguin.net
If you use an ide you tend to not learn some of the knowledge capable from learning from base code. My school offers several computer classes, but all with an IDE. I've petitioned and I'm now taking independent classes WITHOUT an IDE because I want to know the whole language. The more you know the easier it is. I would rather learn the basics from notepad or vim, and then learn to use easier methods. Its similar to driving a stick shift vs an automatic. If you drive a stick you understand how the car works and you need to pay attention, and if you drive an automatic you crash because you have to pay less attention, especially while your shaving on your way to work :)
Support the source, Open Source! An entire site developed with OSS