For some reason, we started using jEdit as our official editor in CS180, since apparently our students weren't hax0r enough to handle Vim or Emacs (we stopped using Eclipse as well, for some reason that I don't really know). Looking back over the past few years, I wonder if jEdit is such a good choice. They tout themselves as a "programmer's text editor," but I think it sucks. We have 25 [apparently theoretically] identical computers in the CS180 lab, but jEdit does wacky stuff like behave really oddly if num lock is on (or off, one or the other), not syntax highlight properly on some computers, etc.
I'm hoping that as the next head/lead/whatever TA, I can persuade the course administrators to change the editor, if I want, but I'm not entirely sure what I would suggest using. The options seem to be:
- Vim
- Emacs
- Pico/Nano
- Eclipse
- IntelliJ IDEA
- NetBeans
Some of these options are laughable (if you ask me, anyway). Using vim or emacs as a main editor is probably still not a great idea; it would be wise to learn in CS180 anyway, but the warring of the two editors means some students would be learning one and some would learn another, as mandated by the instructing TA. This is probably a crappy idea, and students should try both on their own, since the USB has tutorials on both. Pico on lore doesn't have syntax highlighting; I don't really know why we don't use Eclipse (other than I think it can eat poop), IDEA looks interesting (but weaning new programmers on IDEs means they're going to have tons of fun in CS240), and NetBeans? Yeah...
I'm open to opinions, though I wonder if anything will ever come of it. Maybe I'm just posting so I don't feel so lazy.
10 comments:
For a few (quasi-)reasons, I think emacs would be the best choice:
1. Most profs in CS at Purdue seem to push it and use it.
2. It integrates very nicely with gdb and bash.
3. You can run it quickly via ssh (X forwarding of Eclips is just too slow).
4. Eclips and other IDEs tend to hide a lot for simplicity. Once I started using emacs and compiling on the command line, things were much easier to understand.
5. It's very easy to distribute a common .emacs config file to ensure all students have the same environment.
6. You can hit 'tab' anywhere on a line and it will indent it correctly. This helps teach good coding styling as well as helping students find bracket mistakes (which are common with beginners).
One might argue that the learning curve for emacs is a bit steep but really I think this point is childish. These are college students we're talking about here and if they can't figure out an editor that countless others use every day then maybe they shouldn't be in CS.
Yeah, I figured you would pipe in with a word for Emacs. Here's my issues with Emacs:
1. I don't use it, and neither do at least half of the people I have on my list for this fall. One of them used to, but we swayed him to the ways of Vim ;) I tried Emacs for a very very short while (like 10 minutes), but I'm not a huge fan of all these two-chord (VS terminology, I guess) shortcuts. I haven't seen that many profs edit code, but you're right that most of them seem to use Emacs.
2. What about jdb? ;P Okay, seriously, jdb sucks. I also have to write a debugging lab for CS180. No idea how I'm going to do that; it took me quite awhile to figure out how to use jdb, since it's not as much like gdb as you'd think.
3. Vim isn't really any slower, and you don't really need X. You could install Eclipse locally (IDEA is ruled out on that, I think), as well.
4. Yeah, IDEs will do a lot of simplification; I don't really want to use one either, but avoiding editor wars is hard, too. CS159 forces everyone to use Vim, which ends up being an amusing experience, since people can't keep their modes straight. We could go the same route with Emacs, but I'd have to convince myself first.
5. Well, you could do that with Vim as well (and probably Eclipse, etc...)
6. Not sure what you mean by this, Vim (and Emacs) have auto-indenters that [usually] indent properly for each new line when you hit return. Vim 7 has brace/bracket/paren highlighting, and I'm pretty sure the IDEs do as well.
I think the learning curve is kind of an unfair argument. Freshmen are usually tricked into taking an inordinately large amount of credit hours (I took 19); you can't really expect them to become programming wizards in a single semester. I don't really know if Emacs has a steep learning curve to begin with, though, I'm too impatient to figure that out.
For Luke's #4 - I agree that it hides things for simplicity, but for a first semester class introducing people who have never programmed before to programming, it's probably actually a good thing. None of the hidden things would affect their ability to code in java (at least from what I remember from when we were in 180 using eclipse).
Whoa there. I should have made myself more clear. VI/M and/or Emacs. Most of these points were intended for BOTH editors. The debate has been exhausted thousands of times before and honestly they are both just fine. I don't care as long as your using one or the other.
Do you have anything real to say about my comments other than just replying "vim" to every point? Let's see some real discussion here, not this high school emacs/vim debate.
You are way too eager =P
@James: I think the IDE hiding the details is more for advanced programmers. It's really not a simplification if you want to know whats going on and it makes everything you do make much more sense when you see it. Black boxes like this can be bad when your trying to grasp how things work.
I am not really putting in a plug for Vim even if I do use it. The problem is that TAs don't always use the same editor, as displayed, and most of us probably can only help with one or the other, not both. This can cause problems if a lab TA prefers one editor and all of the consulting TAs prefer another one, and a student keeps asking how to do stuff. People these days don't look stuff up for themselves, so I think it'd turn out to be a big hassle.
In my 159 lab, students had to use VIM (which I have no idea how to use). They were given a simple tutorial on it and set loose. It was hard for probably the first 2 labs and then they learned how to leverage their resources (Google) and their fellow classmates (a few who knew way more than me about VIM).
So I think it's a *good* thing that the TAs don't know everything because it teaches the students how to help themselves.
I guess this boils down to: tough love?
Many of the projects in these classes, especially in the beginning, only consist of a few files/classes. I don't see how an IDE such as Eclipse or NetBeans would provide any benefit. The only thing the IDE would be used for is a text editor. Maybe more adventurous would try figuring out the debugger but who knows. That being said, the only important part is actually editing the text, enter emacs/vim.
I would suggest XEmacs. It doesn't have the learning curve of Emacs and provides that same feature set in an easy-to-use package. You don't have to worry about modes, you just type. Later on more advanced features of emacs can be discovered.
Another point against the Java IDEs is exactly that. They are __Java__ IDEs. Most students will have a long road ahead and deal with many languages. Why start them with an IDE that they will just have to stop using the following semester? Give them the tools to be productive in any situation. Also Emacs has Nix/Windows/Mac packages so anyone should be able to use it regardless of the machine.
My last point is about SCM and testing. These are probably not stressed enough. It would be beneficial to learn to take advantage of these tools. To start off and rely on an Java IDE to do it for you is probably not the best idea.
Thoughts?
I would go with Eclipse (portability, ease of use, pretty standard in the industry too).
Sure, you won't use all of the functionality in it, but it's similar to showing how to use .Net to a 1st year student if you're teaching C#.
To Luke's comment about how they are in college and they should be able to learn it... cs180 is an _intense_ course for a first year that focus' on learning how to program. We should try and make it as easy as possible while still allowing the tools they use to be useful outside of the class. jEdit?.... who uses jEdit?? That's a bit WTF imo.
At the same time, I also believe it would be important to let the student know that an editor is just that, an editor. For the most part, it doesn't change the way that your code is compiled. In fact, encourage them to look at others and learn others and have them use one they like the most.
Twinkies will go bad before you convince me that vi[m] is better than emacs, and I'm sure vi people feel the same way about emacs, but who are we to force our opinions onto the people who haven't entered the battlefield?
What I would do is probably use about 15 minutes of a class or lab to explain that they are entering many wars. Java vs C vs C++, Windows vs Linux vs BSD, KDE vs Gnome, vi vs emacs.... Horde vs Alliance. They need to understand that there is _never_ only one option, and that they will always be given a choice and it is what they feel most comfortable with is how they need to approach using their various tools. Let them know that they are _just_ tools to accomplish what they will be learning in this class and that PHP is a tool that is best suited for web programming, while C is a tool that is best suited for speed. You wouldn't program a web program in C and you wouldn't create a desktop application in PHP. Don't interpret these words the wrong way either. There are times when C can be used in the web (Meebo?), and when PHP can be used on the desktop (PHP-GTK), but if you have enough knowledge to do that stuff, then you probably have enough knowledge to make an educated decision.
Oh, and if you made it this far Dan, I'm pretty sure you have my e-mail address so send me an e-mail about the overview of being a CS180 TA, I am pretty interested in helping out if there are spots.
First of all, I agree with you on the jEdit issue. I ran into the Numlock issue many a time when I was helping people during help hours...
I'm pretty sure that one of the reasons we stopped using Eclipse is because the department had issues getting it to work properly. (I want to say it was an issue with switching from Sparc boxes to x86 machines, but I seem to remember the switchover happening while the lab was still in HAAS.) Thus, any using of Eclipse is going to require some checking with the department to see if they would even support the install, let alone using it in 180. We don't want to repeat the fiasco of having jEdit installed to the home directory of everyone.
Also, Eclipse isn't the most friendly (IMHO) in making new projects. While I don't think it'd be a problem once people got use to it, I could see people having a significant problem getting over that first hump. Thus, if we ended up going down the Eclipse path, we may want to look into using Penumbra again. This is what we used in Eclipse freshman year, and I seem to remember it working out pretty well. One of the really nice features was that it was cross-platform; I don't think I ever worked on a project in the lab (other than maybe the GUI project). Unfortunately, Penumbra hasn't been updated in about 3 years, so it may need to be updated. (According to the newly-released Eclipse 3.3 release notes, it's backwards compatible in "most aspects".)
Let's presume for the moment that Eclipse is out of the picture. What's left? First of all, I'm dismissing pico/nano completely, since you might as well be programming in Notepad. That leaves us with the remaining GUIs versus vi/emacs. I'm not completely sure how the department would feel about supporting another program (such as IDEA or Netbeans). That's a major strike against them, and--at least for the purposes of this--I think it's a fatal strike.
That leaves us with everyone's favorite flame fest: vi versus emacs. I've used both of them in the past, and I really don't have a preference either way. (I'm currently using GVim to edit most things, but that's more of a habitual thing than anything else). What I can say is that it's much much easier for people to pick up if they're using a graphical version of the program. If you don't know how to (say) quit out of the editor, you don't have to mess around trying to figure out the magic shortcut key / chord. Instead, you have a nice menu to use. In addition, you can go back to using the plain-Jane text interface if you want (or if you're ssh'd in to a computer).
====
So which one of these would I pick, then? That's a really good question, and I'm not so sure that I have a good answer. Currently at work, I use a combination of Eclipse (for regular programming and developing) and GVim (as a general text editor) on my Windows machine. Eclipse is certainly a very handy program to use and develop in, but I'm afraid that people would really start using it as a crutch more than anything else. If you're used to having your IDE find the errors for you, good luck when you switch to 240 and a lot more forgiving C compiler (read: there's no safety on your gun to prevent you from blowing your foot off). Thus, as much as I hate to say it, I think you really should go with vi / emacs. Which one do you go with out of these two? I think that Emacs will be a bit easier for people to handle at the beginning (for newbies, mode switching really really really sucks!), but using the graphical versions of them might make a difference.
Anyways, that's my personal 2 cents. I'll post a second comment later on tonight with some responses to everyone else's comments.
Funny enough, after digging through the Eclipse website for awhile, I discovered that it's not supported on x86 Solaris. Good thing Java is portable and everything. Eclipse is ruled out now.
Post a Comment