Ah yes, it's time for the perennial IDE flamewars. *dredges out his soapbox* (Who says Course VI students don't use soap?) The esteemed Michael Bolin tells us that bringing JDEE into this debate is cheating, and that the proper comparison is Eclipse versus Emacs-sans-JDEE. We need to carry this to its logical conclusion. After all, Emacs is still far too much of an IDE: even without JDEE, it supports compilation and version control and syntax highlighting and generalized completion and all kind of fancy features. The appropriate comparison, therefore, is between an IDE and a pure text editor: not Eclipse versus Emacs, but Eclipse versus *ed*. It has come to my to attention that some of you young whippersnappers may not have heard of the mighty ed. ed is the Standard Text Editor, dating back to AT&T UNIX V1, back in the day when real programmers were Real Programmers. Jared said that he was wary of tools that would write his code for him. An excellent point! For projects like this, it's important to not only holistically understand the high-level design of the program, but understand every individual line of the code. Eclipse writes huge chunks of your code for you, and even Emacs will write part of each line for you. In order to truly understand each line of your code, you must use a line-based text editor... like ed! With ed, you can attain a blissful Zen-like state by becoming one with your code, since you wrote every character of it -- including the whitespace. ed forces you to think before you code, since changing your code becomes non-trivial. I regularly used ed when I was working on my 6.170 problem sets. IDEs like Eclipse and Emacs separate you from your code, insulating you from the joy of hand-crafting each statement. Since we all know writing Java is so much fun, you get to experience so much more of it with ed. Emacs and Eclipse just suck all the fun out of 6.170. And of course ed is so much faster than Eclipse and Emacs. Eclipse is 80 megs of Java. Just to run it you need to start up an entire Java virtual machine -- a simulated computer, no less! Emacs is 20 megs of Lisp, and it's practically its own operating system. ed is less than 80K of pure, optimized C. ed can start up in less than 0.003 seconds. I'm still waiting for Eclipse to start up -- and I took 6.170 last year! ed's pure speed allows programmers to be increasingly productive because they don't have to sit around all day waiting for their editor to load or run. Some Eclipse zealots claim that Eclipse has a superior interface to Ed. Nothing could be further from the truth. Let's take a look at some of the 6.170 user interface heuristics from last semester and see just how well they apply to ed: "10: Aesthetics and Minimalism - 'Less is More!'" "2: Consistency and Standards" Minimalism? You can't get much more minimalistic than ed. Let's look at a typical user session: dan@AMBULATORY-CLAM:~ 1028> ed Gizmoball.java 1263 1i ; Convert Java to Scheme . ,s/^[:blank:]*\(.*\)=\(.*\)/(define \1 \2)/ w 1333 q A complex transformation performed with a minumum of user interaction! (Recall that we want to "provide shortcuts for common commands". In ed, everything is a shortcut, so we even have shortcuts for uncommon commands!) Notice how ed gives the same response to each command, indicating that it was successfully performed (consistency!). Both input and output are kept to a minimum. ed does not overwhelm the user with verbosity. If "less is more", then ed is paramount. "5. Visibility of System Status: keep user informed of system state, but don't overdo it" Certainly no one could accuse ed of overdoing it. We know that an operation seems instantaneous if it takes less than 0.1 seconds to perform it. Since everything can be done this quickly in ed, it just feels faster. And there's no need for silly chrome like progress bars. Eat that, Eclipse! "9. Error Reporting, Diagnosis, and Recovery A good error message should ... avoid technical terms and details unless explicitly requested ... and be polite" ed reports errors in a minimalist, consistent way. Every error gives a polite message that informs the user that something went wrong, but doesn't burden the user with a complicated technical explanation of the error: dan@AMBULATORY-CLAM:~ 1030> ed ? help ? ? ? quit ? exit ? i hate myself and want to die! ? ^C ? ed is clearly the right choice if you want to gain a superior understanding of Java. After all, if you're stuck on a desert island with a PDP/11 and a teletype and forced to churn out Java code, you'll need to be able to write it without the aid of an IDE. The PDP/11 certainly can't run a Java VM, so you can't very well use Eclipse, and even Emacs can't run on a teletype. But ed can! In these uncertain post-9/11 times, we have to stick to reliable, time-tested tools like ed. Unlike these new-fangled ideas like IDEs, ed has been the choice of Real Programmers for decades.