Visual Studio vs. Eclipse: a Programmer's Comparison 543
Nerval's Lobster writes "Developer and editor Jeff Cogswell is back with a comparison of Eclipse and Visual Studio, picking through some common complaints about both platforms and comparing their respective features. 'First, let's talk about usability,' he writes, 'and let's be frank: Neither Eclipse nor Visual Studio is a model for sound usability.' That being said, as an open-source project, Eclipse wins some points for its customizability and compatibility with languages; it's more difficult to modify Visual Studio to meet some programmer needs, which has led to any number of abandoned projects over the years. Microsoft choosing to eliminate macros in recent versions of Visual Studio has also led to some programmer frustrations (and a need for external tools)."
Out of the box (Score:4, Insightful)
Out of the box, VS wins hands-down.
Um excuse me ... (Score:5, Insightful)
A developer with sufficient skills can be productive in ....
A developer with sufficient skills can be productive in anything.
vi.
gedit.
emacs/xemacs
Pencil and paper.
And on very VERY rare occasions, I've seen developers who did everything their head and just typed in any old text editor.
No point (Score:1, Insightful)
Title not a good start (Score:3, Insightful)
This is not a good sign. A developer with sufficient skills can be productive using vi as her IDE...
Reviewer doesn't know the first thing! (Score:3, Insightful)
"Studio also requires a working set of about 250 megabytes of memory, while Eclipse requires about 3 megabytes of memory..."
Erm, working set on a newly launched eclipse (no project) takes 13x,xxxK.
Plus working set is actually a GOOD thing - in theory. Imagine two programs which each take 700 megabytes running on a machine with only 1000 (and 24). Imagine them sharing some ... libraries, we could call them, of 500 megs each. So the working set would only be 900! Yay! Disk thrash averted :)
Oh, DLL hell? Ah.
Yes.
A real study is needed (Score:4, Insightful)
As far as I am concerned, IDEs are largely similar in their view of software development. They are like bloated bureaucracies that one has to deal with to do anything constructive. If you dare have a project format that VS, Eclipse, or what have you, doesn't understand, and you have to set up the environment to do everything manually. I know I sound like I am saying "Get off my lawn," but I am really saying we need to understand the development process better. IDEs obscure it too much. Tools like VIM and Emacs expose 100% of it. (In full disclosure I use VIM, ctags, make, etc.)
We need to come up with the programmer's equivalent of the SAE and define basic tools of the trade. It will never happen, of course, but that's *really* what we are fighting about.
Conclusion: meh (Score:5, Insightful)
So the conclusion is "both work; each has some flakiness".
That's a long-winded way of saying "meh".
vi or emacs debates anyone?
Re:Studio v. Eclipse (Score:4, Insightful)
Left out MyEclipse and IntelliJ (Score:5, Insightful)
You're comparing an expensive IDE to a free one. I'd be more interested how it compares to a curated Eclipse experience like MyEclipse or a closed source IDE like IntelliJ. All that being said, Eclipse is mostly used by folks using Java or languages that run in the JVM. Visual Studio is going to be used by those on a Microsoft stack.
Getters and setters (Score:4, Insightful)
"One full-time Java programmer told me that he hasn’t had to manually type in any setters and getters in years, and he has a template from which all his objects are typed in automatically, thanks to the code snippet tools in his favorite editor (which isn’t Eclipse—he uses IntelliJ). Clearly, methods of automated typing seem to be a favorite among a lot of programmers. So why did Visual Studio remove a feature that facilitated this? Who knows."
Let's not mention the fact that in C# you don't need to manually type in all the getter/setter junk, just public int MyField {get; set;}
Re:Title not a good start (Score:3, Insightful)
This is not a good sign. A developer with sufficient skills can be productive using vi as her IDE...
Yes, but not as productive. Yes, it's true. It's been measured. A skilled coder, working in an IDE, can run rings around the coder working in a text editor when the "product" is something more sophisticated than "hello world".
This article lacks the most important thing: debug (Score:2, Insightful)
Yes I use IDEs for coding, and I want to be confortable using syntax highlight, shortcuts and fancy tools. But the most important feature I want is to have a professional and versatile debug interface.
This article sounds like the propouse of an IDE is to be super fancy text editor.
From my point of view, the capabilities of Visual Studio for debugging are far better developed than the ones in Eclipse.
- My two cents.
Re:No point (Score:3, Insightful)
The bulk of new development is Java/C# these days. It's for the best really - have you seen the sort of C++ a "Java programmer" will write?
Re:Studio v. Eclipse (Score:2, Insightful)
Re:Studio v. Eclipse (Score:4, Insightful)
Re:Um excuse me ... (Score:4, Insightful)
I don't know, great editor but lacking a bit to make a good IDE. I don't like IDEs though so I don't mind that. The whole concept of having a single window to view code in that is surrounded by auxillary rarely used windows just seems backwards, and yet that seems to be the dominant design. Also the idea that all tools must be a part of the same overarching tool seems wrong, since it prevents you from mixing and matching the best tools. Ie, if you have an IDE with a great editor but its debugger is mediocre, then the entire IDE becomes mediocre; in some cases I have seen some developers use several IDEs in parallel to get the best of each, which also defeats the idea of "integrated".
Emacs does what is important with an IDE, lets you edit, lets you run a debugger and present the data within it, lets you start a build and present the results within it, and lets you manage the source code control. Basically it has a way to integrate other text based tools. It doesn't need to be a Windows style MDI application to do that.
First IDE I used was in 1981, UCSD Pascal. Edit/compile/debug in a straight forward tool. Things do not seem to have improved that much since then. Maybe they're prettier though.
Re:Um excuse me ... (Score:4, Insightful)
Fired? That's ridiculous. Let the developers use the tools they are comfortable with.
If you're doing a 3 second refactor with a tool then that means you are not cross checking to be sure that the tool did it right or the way you wanted it done, so add at least an hour to do that to do it right. Never trust a tool to do the right thing, unless you're in the sort of dysfunctional environment where fast code is more important than correct code.
Re:Studio v. Eclipse (Score:5, Insightful)
VS was the best debugger in the business, and if you're stuck with a legacy code base that's arguably the most important part of an IDE. And back when MSDN was installed with VS (instead of being a web site) it was amazing for its time, because you could select any library function name and with a keystroke get really well written docs for that library function fast. I used to have half my screen for code and half for the doc pane. Once it became wait-a-few-seconds-for-the web-page, that advantage was lost.
Re:Um excuse me ... (Score:5, Insightful)
Well, I'd never hire you in the first place, because modern IDEs are the automation of the software development world and demonstrably improve productivity while lowering error rates.
You're basically saying that we should let the guys in the warehouse manhandle 500kg loads by hand because they "prefer" not to use the forklifts. We should just let them do whatever they please, because that's what makes for good management, right?
I've been in mixed work environments before where everyone just used whatever tools they wanted: Linux, Windows, Mac, Vi, Emacs, etc... I personally used IntelliJ IDEA on Windows because it had code analysis and safe refactoring. My productivity was at least 50x higher than other developers. I was told not to submit changes too fast because the code reviewers couldn't keep up. Note that I didn't say I was 50x better than anyone else -- there were smarter and more experienced developers there -- but I was running circles around them because of the tools that I was using. A woodcarver, no matter how skilled in his art, simply cannot keep up with a CNC milling machine. A blacksmith cannot possibly outproduce a ten ton press that can stamp out a part every five seconds.
Inefficiencies were everywhere: they took 30 seconds to check out a file from source control using a command-line tool, whereas I could just start typing with a barely noticeable pause on the first character as the IDE does it for me. They used "diff", I used a GUI 3-way merge tool that syntax highlighted and could ignore whitespaces in a semantically aware way. There was one particularly funny moment when some guy walked up to me to ask me to look into a bug in a specific method. He starts off with the usual "now go to the xyz folder, abc subfolder, now somewhere in here there's a..." meanwhile I'm staring at him patiently because I had opened the file before he'd even finished giving me the full method name at the start of his spiel. Global, indexed, semantic-aware, prefix search with jump to file is a feature of IntelliJ IDEA, not Emacs or Vi. He's never even heard of such a thing! Thought it was magic. Grep couldn't have found the method anywhere near as fast, not through 30 million lines of code anyway, and then it would have returned every reference to the method name as well, not just the method definition itself. Then I'd have to find the damned file in a haystack of thousands and open it manually anyway.
Minutes of work in a seconds, hours in minutes.
It's not about typing, or shortcuts, or block select, or the specific dialect of regular expressions in your favorite text editor. It's about indexing, refactoring, code analysis, live error highlights, popup-help, tab-complete, source control integration, boilerplate generation, integrated debuggers, and a thousand other things that most programming oriented text editors simply do not have. It's about letting the CPU in your computer do what it is there for, instead of just waiting patiently for the next keyboard interrupt so that it can use all 3 gigahertz of power to put a byte into a buffer and then go back to sleep.
It's not even a good idea to let developers pick their favorite IDE either, because there are productivity gains to be had from consistency. Training is cheaper, licenses can be purchased in bulk, plugins will work for everyone, custom extensions may be cost-effective to develop for one IDE but not many, etc...
Re:Studio v. Eclipse (Score:4, Insightful)
Somewhere about 5-8 years ago there was a distinct and obvious transition between MSDN docs written by good tech writers, and MSDN docs clearly written by devs - unsurprisingly this was about the time auto-generating docs from docstring comments became the thing to do.
The docs for the old win32 stuff are still good though. Look at the docs for the famously-silly CreateFile() [microsoft.com] function. Everything is explained, including all the corner cases, but critically there's also the vital "but you probably just want to do X" hints that are so needed when the docs get this long.
Contrast that with File.Create() [microsoft.com] which only hints at what the various options do (but at least has proper grammar, unlike some of the seldom-used stuff).