A pointer to an article comparing Visual Studio and Eclipse has been posted to Slashdot. The article isn't really strong, but I am finding a ton of value reading the comments on Slashdot. The people there make a lot of good points and there is even some discussion on the CDT.
It's interesting to see that the number of pro-Eclipse versus pro-VS comments is pretty even. One thing that I did pick up from it for Eclipse, other than a bunch of usability concerns, is that if we truely want to be compared to VS, Eclipse really needs to support .Net development. That and we really need a GUI builder. I wish I had more time to take a look at NAB and see if we can use it more generally as the NAB team suggests.
I've thought about .net support as well. I work on a C++/C# team and have tried to change the mindset from "Visual Studio is the only way", to "Use the best tool for the job". I've started down that path by using SCons to build our code instead of MSBuild/Nant and generating our projects on the fly instead of relying on them as the source-of-truth for our build.
ReplyDeleteIf I could then show them another IDE that works better than Visual Studio once you understand it, I think we could really make some headway. Of course, there are always those who eschew anything not written in C# or running on top of the .net vm, but that's not the audience I'm trying to reach, either, because they've already made up their minds.
Now the question is, where does such a project begin? Does it build on top of CDT? Does it fork JDT (which is probably too tightly coupled to java)? Is it a new project altogether, reusing pieces where it can?
And about the GUI builder, Visual Studio's GUI builder falls on it's face in many places when the UI code starts to become more than trivial. I work next to our UI person who does ASP.net pages for our product and I hear him complain almost daily about the asinine things VS's web UI builder does.
ReplyDeleteThis is merely a personal opinion, but most GUI builders seem to be more for marketing purposes. For him, it's gone from drag 'n drop the UI to a poor man's preview page. He's found a lot more success with tools such as the Firebug extension for Firefox, which let's you make changes to CSS and HTML and see them in real time.
I'm confident that C# can be done using the CDT. We have Fortran with Photran and will be working with the new Ada project. I already have a build and keyword highlighting solution for C#. The hardest parts would be indexing and debug.
ReplyDeleteAs for GUI builders, you may be right. But as table stakes for new users, it's probably a high priority for some.
How hard would indexing be? And would it be able to work off the metadata in assemblies, or from source code only?
ReplyDeleteCurrently we are creating assemblies from linked netmodules and Visual Studio itself can't index those (I don't see any plans for them to support that in the near future either). I would be interested in what a custom indexing solution could offer.
You would probably need both since C# doesn't have header files. You need to at least get that information from the assemblies. There are pretty good APIs to do this, though, so it shouldn't be hard.
ReplyDeleteFeatures like content assist will at least need to be able to parse the source of the current file, so we'll need a parser too. I've started one using ANTLR but I just haven't have the time to work on this much lately.
As a C++ user who doesn't do any .Net programming, I would much rather you continue the improvements you have started with CDT 4.0. Eclipse and the CDT for me has just become usable as a text editor, nevermind a serious alternative for commercial IDEs. Content assist (or Intellisense, or code completion, etc.) is sometimes usable, but often out of date or empty. Debugging still has a long way to go. It works sometimes, but it is often easier to use the commandline gdb. I'm excited about the improvements in CDT 4.0 and what it could be in upcoming releases, but please continue refining the C/C++ functionality! I would much rather have to look elsewhere for .Net tools if I ever need them, than have a single solution for everything I could possibly want to do with a "C-esque" language but that doesn't do any of them particularly well.
ReplyDeleteI agree, it would be nice to see Eclipse become a strong IDE for Mono developers. But I wonder if some .NET/Mono developers are put off Eclipse by the fact that it runs on Java.... I think this can be a problem for some C/C++ developers as well.
ReplyDeleteCan Eclipse run on IKVM?
Luckily I'm not the only one working on the CDT. The team will continue to work on fixing any issues we have. All of us are delivering the CDT in our respective commercial products and we need to keep our customers happy.
ReplyDeleteAs for being written in Java, I think that puts off contributions from some. I don't see why users of Eclipse should care what language it is written in. I'd love to see us be able to write Eclipse plug-ins in other languages but that's not always the best answer either.
I just took CDT 4.0 for a test drive. Nice work on the indexer! I've used SlickEdit for years for all my C++ projects and the code completion has always been better than VS. But for some reason it has problems tagging wxWidgets. Now CDT is working better than SlickEdit! Still some problems getting code completion to work with some controls like wxButton for some reason. Don't know why, but in general it's working very nicely. Great work!
ReplyDeleteCool. Thanks. Now that wxWidgets is part of Wascana, I'll be using it more with the CDT and hopefully start fixing any content assist bugs that I find as well.
ReplyDeleteThe purpose of the article was to focus on the basic IDE features and avoid discussion of a particular language support (which as you pointed would be comparing apples to oranges).
ReplyDeleteAnyway, I'm really looking forward using the "File->Import->From .csproj" option :)
I think C#/.NET support should be an independent project, not based on either CDT or JDT. If one day you decide to support VB.NET will you still build the support on top of CDT?
Maybe .NET support in Eclipse should follow the original MS idea - have some common support for .NET as a platform, and then build CDT support for Managed C++ and some new projects supporting C# and VB.