Slashdot Mirror
Comparing Visual Studio and Eclipse
An anonymous reader writes "Getting started with Eclipse can be confusing. New concepts, such as plug-in architecture, workspace-centric project structure, and automatic build can seem counterintuitive at first. Without waxing too philosophical about IDE design, this article presents the main differences between Visual Studio and the Eclipse IDE."
Well, I've been using both every day for years now. As always there is no black and white but there is a lot of grey there in between. If I need to chose, I would chose Visual Studio any day. That doesn't mean that it's perfect: it's not, but it simply feels better for my needs. My subjective opinion is that VS feels a lot more "solid" to me, faster and "logical" to my Borland eductated tastes. Havig support for C# is also a big plus to me, but that has nothing to do with the point of the article. Being OS is nota plus in my book, because I really don't prefer OS over commercial or the oposite just for the sake of it... I'm not religious in any shape or form. My 2 euro cents.
It's time to realise that Abble's products are the biggest abomination these days. Just say NO to the dumb iAbble way!!
Personally I love Eclipse. Working in an environment where I was required to rapidly switch between Perl, C++, Java, and Oracle, Eclipses perspective system is a godsend.
.NET. I think the main reason for this is that Microsoft holds all the cards. They don`t have to accommodate a million developers tool preferences, because they define the tool set. I`m not saying this is a good thing, just that it makes a perfect foundation for building a powerful IDE.
The only problem is it's so damned bloated. It wasn't until I used it on a powerful server-turned-into-a-workstation box that I found eclipse usable. On a standard system, it's just too laggy.
Even disabling some of the heavier features, I find it hard to get any work done when not using it on a system with 4 GB of ram and two processors.
Visual studio on the other hand I think is the perfect IDE for
Eclipse>Visual Studio
Which would be funny, except that for the languages supported by Visual Studio, the correct version is Visual Studio >> Eclipse.
Eclipse does fine on its home territory as a Java IDE, but the plug-in system is way too disorganised and underpowered for serious development in, say, C++ or C#. Even if you use CDT for C++ work, it's basically hopeless unless you're combining it with GNU tools, and things like the debugging tools aren't even close to the power of VS.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
and Intellij > Eclipse
I've been using Eclipse professionally for some time and the only recent Visual Studio experience I've had has been working on some sparetime C++ project with a buddy. But from that I seemed to notice that the intellisense kind of feature and other assisting tools seem far more evolved in Eclipse. For instance, Visual Studio will sometimes fail to find the members in an object when I type <object><dot> and this rarely fails in Eclipse (unless there's a syntax error).
Eclipse also assists in further ways I'm missing from Visual Studio. It highlights syntax/parser errors, a feature which might seem annoying until you realise that Eclipse will help you solve it. This will save you from a lot of typing effort if you use it to your advantage. If you assign a value to an undeclared variable and press Ctrl+1 on the error Eclipse will offer to declare the variable either locally or as a field. If you instantiate a class, or access a method/field that doesn't exist Eclipse will offer to make a stub for you.
It's features like this that has turned Java from a hideously verbose language into something that's almost easier to develop in than Ruby (imho), and Visual Studio seems almost antiquated on this subject (there's no excuse for not implementing these features for statically typed languages such as C/C++)
It's a great platform but it's an utter pain dealing with the plugins and the varying degrees of compatibility. MyEclipse makes it substantially better though.
Mod this guy up. Seriously, I don't even know how you would do a comparison of 2 products that don't compete against eachother. Sure the are both IDEs, but one is mainy for Java Development, while the other is for .Net,C++. Comparing features and how easy to do things would be nice, but the major deciding factor for most people will be which programming language they are using.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
I use Eclipse for PHP development using PDT, and it's great. Zend Studio Pro costs $299, and comes with debugging support, but you can get the same thing with Eclipse for free, and support various other languages as well.
.NET development, or developing specifically for the Windows platform using an MS supported language then of course VS.NET is the obvious choice, but Eclipse is good too.
If you're doing MFC, or
It's also encouraging that enhancements can be written for Eclipse easily without IBM worrying that your enhancement will stop people upgrading to the Pro edition.
I think that because IDEs for any language all share so many requirements, and because they're used by developers who will want to improve it, it makes a natural open source project, and I expect as time goes on it'll get better and better.
// MD_Update(&m,buf,j);
Real programmers do not need debuggers ;-)
Seriously, I have been using eclipse for years and I don't even know how to invoke the debugger. Nothing I hate more than an IDE falling into debugging mode when an error is encountered. A stack trace is fine with me. When really stuck, I insert debugging statement in the code in the relevant places.
Of course, I realize that this is my old way to view things. I also know that modern development teams would go on strike if I tried to impose them an IDE without a debugger ;-)
So, view this as my 2 cents, nothing more ;-)
Everything I write is lies, read between the lines.
That all depends. The suite we were using in CS had a debugger, but it didn't pop up unless I explicitly added the break points. It was an irritating IDE in many ways, so many times I would on short code be left to boggle as to why it wasn't able to read what was typed. Sometimes it would inexplicably fail to read the closing brace even if it were only two lines down.
A good debugger can be a time saver, but one should really only need it if the program is large enough that it isn't clear as to where a variable changes to something naughty. Yes of course, one could do that by hand, but that isn't necessarily the same, every once and a while there is a genuine bug in the compiler or something isn't being done the way that it should be, and paper tracing isn't going to find that.
I would be curious as to how you handle code which is separated into many files to keep things small and comprehensible. Of course each file is easier to fix, but I am somewhat curious as to how you deal with the interactions between multiple source files. And more specifically all of the flipping between source files that can happen with a more complex program.
Compiling Java Code to x86 before run-time won't make it faster but a _lot_ slower. A JIT can do a lot of run-time optimization that just isn't possible with GCJ. For example, functions often cannot be inlined at compile-time, while they can at run-time. Also, you can use the whole instruction set when you JIT - if you don't, you're limited to i586 or i686. The next thing is that a JIT knows what kind of data is being processed allowing further optization, while an ahead-of-time-compiler can only guess about this. And GCJs garbage collector just sucks, since it's a non-moving Collector, which was originally developed for C and C++. Thus, it doesn't exploit the fact that java references are completely opaque, allowing yet more optimization (read: moving garbage collectors).
On the downside, a JIT uses more memory, because the code is in the memory twice (once in bytecode form, and once as native code). And of course, you have to do the actual JITing, which is negligible on today's machines once the program is up and running.
The only reason why Red Hat ships x86 binaries instead of java byte code is that for whatever reason they didn't want to include Sun's JRE (probably the same reason why they don't ship proper multimedia support or NTFS drivers).
My argument is that community-supported Free & Open Source Software solutions a superior IDE make.
Thats not an argument, thats a statement. So far you've presented nothing to back it up.
Here is the list of operating systems that will run Microsoft Visual Studio 2005:
In addition to the list of operating systems above, here is the list of operating systems that will also run Eclipse:
This looks like a shameless plug, trying to get you to buy this Eclipse Sucks t-shirt, but really it's just anti-Eclipse evangelism (or is it, "Eclipse anti-evangelism"? ;-). It will fall on mostly deaf ears hear in Slashdot-land, where I expect most people who give a crap about Eclipse one way or the other will be of the uber-geek type who LOVE it.
But, what the hell. Maybe some will get a chuckle out of it. :-)
Here's a bit of the text from the "back of the box" image:
Cool funny t-shirts for geeks, gamers and everyone else
Notice that the comparison didn't talk about actually RELEASING the product.
I've spent some time building an application in SWT, which is reasonably sweet and sophisticated -- however, now that I'm looking to release my application, I'm having to experiment with applications to bundling third-party products, experiment with batch launchers, learning how to manipulate jar files, etc.
I wrote a C# program in VS a few months back, and on top of the immediately present and obvious GUI manipulation tools, the ability to just take my exe and run it on another machine without doing further research was a nice benefit.
Why are you letting these clowns ruin our country?