As Harry Hill might say, "I like Visual Studio. And I like Eclipse. But which one is better? Only one way to find out…" For a lot of people a lot of the time, the question is irrelevant. If you are doing Java development, you are going to pick Eclipse, and for .NET development you are going to pick Visual Studio. But both IDEs are extensible, and have communities providing extensions for other languages, so if you are using another language it might not be so clear cut. And if you are a language vendor wanting to provide an IDE to support developers in your language, then you can use either Visual Studio or Eclipse to provide you with a framework to add support for your own language.
At Micro Focus, (where I work), we've done exactly that. We've added support for developing COBOL applications to both Eclipse and Visual Studio (see the Visual COBOL site for more info). In Visual Studio, we can compile COBOL to either native (x86 or x64) code, or to .NET code running on the Microsoft CLR. In Eclipse we support native code (on Windows, Linux, AIX), and we are adding support for compiling COBOL to Java byte code to run on the JVM (we've actually had JVM support as a technology preview since last year – full release is due later in 2011). I've worked for quite a few years on the Visual Studio side, and for the last three months, I've been working with the Eclipse team. This brings me to a disclaimer – I know the Visual Studio platform much better than Eclipse, so although I will try to be fair to both platforms, there is a lot more I don't know about Eclipse than Visual Studio.
Eye candy
Both IDEs are very sophisticated visually, enabling you to open multiple documents simultaneously, giving you different ways to arrange editor windows, and providing lots of different navigation views to help you find your way around. One of the strengths of a good IDE is that it helps you make sense of very complex projects that might consist of thousands of source code files. Both IDEs do a good job here. They also automatically switch to different views depending on whether you are editing or debugging to help you see the most relevant information for the job at hand. For example, when you are editing, the call stack window isn't telling you anything so you don't want to see it. Both IDEs also let you customise the views (or perspectives as Eclipse calls them) while you are working – any changes you make to windows displayed and their positions is persisted automatically so you quickly end up with an environment that works for you.
However, Eclipse actually explicitly names its different perspectives and you can switch between them yourself by clicking a button – so you can go back to the Java view from the debug view while you are debugging because it might provide an easier way to navigate to some other piece of code than trying to find it in the debug view. Visual Studio doesn't offer the facility to switch between named views, and yet I've never missed it. I think the reason is that although both IDEs offer excellent window management, Visual Studio is just flat out better at it. It is designed to run in one environment only, Windows, and exploits every feature of that platform. Eclipse runs on Windows and a number of Linux and Unix desktop windowing environments, and just doesn't seem to exploit your desktop real estate as effectively. Borders are narrower in Visual Studio, and I always feel like I can just see more of everything.
You can exploit multiple monitors using either IDE. Eclipse lets you open an extra window – essentially a duplicate of your current IDE with all the menus and windows you have in the current one, which you can then drag over to a second monitor. You can then drag windows back and forth between the two IDE instances, which provides a lot of flexibility. But Visual Studio lets you tear off ANY window in the IDE and drag it out to a separate monitor, where you can maximize it, or share the space with something else. It feels very intuitive and slick, and leaves Eclipse looking slightly clunky in comparison.
And when you add in Visual Studio 2010's other fancy features, like true-type fonts and an ability to zoom in or out the text in your editor window, it is the better looking IDE by far.
Coding Productivity
I'm only going to consider this for the IDEs' native languages – Java for Eclipse and C# (I could equally have picked Visual Basic) for Visual Studio. That's because these are the languages that do the most to exploit the features of the platforms they are on. Other languages do not always use all the available features.
Both Eclipse and Visual Studio provide masses of programmer aids, many of which are similar in both IDEs. You get automatic syntax checking as you type, with errors highlighted immediately. You also get auto completion which saves you the effort of remembering the huge APIs presented by the Java or .NET class libraries – and of course auto-complete will also help you when using your own classes. You also get lots of help with navigating and understanding your source code – you can jump straight to the definition of any symbol, or query to see every place where it is referenced.
Visual Studio provides a slightly nicer experience when the source code for something isn't available when you go to the definition of a type; it constructs a source code view of the public members in the language you are programming in (Visual Basic or C#). Eclipse also shows you the definition from the metadata, but it doesn't attempt to construct it as Java source code and it isn't as easy to read.
But Eclipse has a couple of killer features for productivity. The first is automatic builds; by default, every time you save a change the project is rebuilt. This is an incremental build and incredibly fast even for a really large project. Effectively, Eclipse removes the build step from your "edit, build, debug" cycle. Visual Studio can build a C# project very fast when you want to debug it, but it isn't quite the same as it always being ready to go. Eclipse also has an autofix feature for many coding errors – hit Ctrl+1 or select Quick Fix from the context menu when you are over a highlighted error, and you are offered all the likeliest options that will fix your problem. Visual Studio offers a similar feature through Smart Tags (a small blinking underline that can be expanded into a context-menu), but it doesn't cover quite as many situations.
Eclipse wins this category, if only by a fairly small margin. However, if you are designing user interfaces, Visual Studio's form designers (for Windows forms, WPF or ASPX) tip the balance the other way – you can build the UI for an application very quickly by dragging and dropping.
Debugging
You can debug your code or attach to it after it has started running with Visual Studio or Eclipse. Both let you see the call stack, and let you view and change values in variables. You can set breakpoints, step into or over code… all the things you'd expect from a modern debugger. And both debuggers can often let you edit and continue – you're debugging, you change a line of code and it is recompiled instantly into the app you are debugging (although you'll sometimes get told it isn't possible and you'll have to restart if you want to pick up the changes). However, there are a few differences. The main differences in the debuggers are more down to the limitations of the different virtual machines for Java and .NET.
Visual Studio lets you reset the execution point– a really handy feature in my opinion. Maybe you stepped over a piece of code that didn't do what you expected and you'd like to go back and step into it – without starting all over again. Or maybe you know the next block of code is going to do the wrong thing and you want to skip it for now because it has taken you ten minutes to get here… and you don't want to start all over again! The best Eclipse will let you do with Java is drop back to the start of the current stack frame (the top of the current method). Visual Studio will also let you debug managed and unmanaged code as part of the same debug session – useful if you are calling native COM code from .NET or vice versa, or using PInvoke to call native code.
Java can also call native code through the JNI mechanism, but as far as I know there is no way of stepping between your Java code and native JNI code in a single debug session – so if you've got a knotty interop problem to sort out you are going to have to look at the two sides of your code separately.
On the other hand… Eclipse is much better at managing multiple concurrent debug sessions – handy if you are developing some kind of client server app and you want to see what's going on in both sides. For Visual Studio that is quite often going to mean using two separate IDE instances, although you can set a solution to allow multiple startup projects which does make it possible to debug a web service and its client at the same time.
With Eclipse you can also save as many launch configurations for debugging as you want, with different startup arguments, environments and everything else. And you can export the launch configurations to external files for sharing with the rest of your team. Visual Studio doesn't give you as much help here, allowing you to have one set of debug arguments for each build configuration you've set up. And the debug arguments are held in user specific files not intended for sharing between users and machines.
Honours are fairly evenly split in this round.
Project Management
Visual Studio and Eclipse both manage code in projects. A project is any collection of source files that build into "something". For Visual Studio the something is fairly easy to define – it is either a DLL or an EXE file (or a website). For Eclipse, you are going to end up with a bunch of .class files in a bin directory – because that's the way Java works.
In an Eclipse project, any source file in a marked source directory is part of the project. In Visual Studio, source files must be in a source directory or subdirectory, but they must also appear in the project file to be part of the project. The Eclipse solution is simpler, but the Visual Studio allows for more flexibility. You can exclude a file from a project without deleting it, and add it back in again later.
Projects for both IDEs can be stored in your favourite version control system, and since all project files are text they can be diffed just like source code so you can see any changes.
Most significant pieces of software these days are likely to consist of more than one project, and it is here that Visual Studio and Eclipse differ. Visual Studio enables you to group projects into solutions (represented by .sln files). These are also text files that can be stored in version control and shared easily between team members.
Eclipse uses the workspace to group together projects. A workspace is a directory structure rather than a single file (projects do not have to be stored physically within the workspace although that is the default behaviour). Workspaces tend to be machine specific, and also contain all your preferences and settings. They cannot be easily shared between team members, although you can import a group of projects into a new or existing workspace very quickly.
Although workspaces have some advantages (you can have different workspace preferences for different sets of projects), the inability to share them is a pain. And if you have external dependencies to manage for building your projects, these often have to be set up by each team member individually in their workspaces. You can often simplify this down to maybe one or two external variables pointing to the root of the directory tree with your external dependencies, but even so…
By contrast, Visual Studio is quite happy to point a project at an external dependency outside the projects root directory. And as long as those dependencies are on the same drive, it will put in a relative path for you. So as everyone can check out or create the same directory structure, projects and solutions will work on everyone's machine even if John is keeping his sources under c:\source and Joan is using c:\dev.
Visual Studio wins this one.
Shared Build Environment
Shared build environment leads directly on from the previous section – Visual Studio is already ahead here because it has shareable solution files unlike Eclipse's unshareable workspaces. But Visual Studio goes a step further; building from the command line and the IDE is exactly the same because the IDE uses MSBuild, Microsoft's all-purpose build engine, which you can invoke from the command line without using the IDE. By contrast, although Eclipse uses Ant to build, it uses its own version of Ant – which is probably subtly different to the other Apache Ant you've installed on your harddrive.
Eclipse does have a way of doing headless builds (ie using the Eclipse build engine without starting the IDE GUI) which gives you an option for command line builds, but it isn't particularly easy to use or set up in my opinion, and since you are invoking a class in jar file with a versioned filename, you need to change your headless build scripts each time there's a new version of Eclipse.
But to build a Visual Studio solution from the command line doesn't get much more involved than this:
Msbuild whizbang.sln (you'll probably need to specify the platform and configuration as well, but it still isn't terribly hard)
But doing the same for your Eclipse workspace is going to involve you in creating some extra build scripts.
Visual Studio wins here, and by a substantial margin.
Extending the IDE
Both Visual Studio and Eclipse are extendable. Eclipse has a well-documented plugin structure that enables you to extend any part of the IDE. Visual Studio can be extended either through Add-ins or packages. Add-ins are generally for smaller self-contained pieces of functionality, generally using Visual Studio's automation model. If you want to add support for a new language, you'd create a package. Visual Studio also has a macro recorder that can record a sequence of actions and save it as a VBA script.
So which is easier? Microsoft have made huge strides over the past few years in making Visual Studio much friendlier to third parties wanting to add new functionality and languages. There is a huge amount of documentation on MSDN, blogs from many of the VS devs, lots of examples, and so on. But Visual Studio also suffers from having started as a C++ with COM interfaces everywhere, which Microsoft have been scrambling to replace with the Managed Package Framework over the last few years. So there tend to be several ways of doing everything (although to be fair the documentation will generally guide you down the managed route these years).
Eclipse has a plugin structure designed around XML configuration files which enable you to say: "Construct one of these when you do X". And because it is open source, when things don't work the way you expect, you can step straight from your code into the Eclipse code which gives you a pretty good chance of working out what's going on. When things don't work the way you expect in the Visual Studio world it can be a lot harder to figure out why.
Both Eclipse and Visual Studio have huge frameworks and codebases, and it takes a long time to become a real domain expert in either (I haven't been doing Eclipse long enough to claim real expertise here yet). They both do a lot of the heavy lifting for you if you want to provide a good development experience for a given language, but you are also going to have to do a lot of work yourself.
Which is easier? I'd have to say that Eclipse probably comes out ahead here, if only because you can see the source code for yourself.
And the winner is…
On points, Visual Studio comes out ahead 3-2 in this short tour. But, depending on your requirements and preferences, it could easily swing either way. Users expect more and more from an IDE these days, and the cost of developing one from scratch is prohibitive unless you have very deep pockets. Eclipse and Visual Studio both give you the infrastructure to provide a really great user experience; Visual Studio is obviously only going to run on Windows so if you want to develop on other platforms Eclipse is now the winner.
And of course there are other ways to expand an IDE apart from adding new languages. There are hundreds of 3rd party tools and extensions (both free and paid for) for both Visual Studio and Eclipse, providing all kinds of productivity tools.