Picking the Right Eclipse Distribution 78
Someone over at IBM Developerworks who prefers anonymity writes "Depending on what you want to do, there is probably a commercial or free distro built on the Eclipse platform waiting for you. From C/C++, Ruby, PHP, Groovy, Java, and Web development, you can use an IDE built on Eclipse to help you. The big question is: Which Eclipse distribution is right for you?"
Editor vs OS vs Eclipse (Score:1, Insightful)
If you want an OS: Emacs.
But not slow Eclipse.
Slashvertisement (Score:2, Insightful)
Re:Whichever one doesn't require Java (Score:5, Insightful)
Re:Whichever is most popular. (Score:3, Insightful)
It's all matter of taste and what you need. The good thing with Eclipse is that it's relatively easy to start with and you can adapt it to your needs.
MOD PARENT UP (Score:1, Insightful)
I don't think I've ever worked on an eclipse project for significant time without it crashing. The biggest issue tends to be eclipse *running out of memory* on big projects. This often still occurs when I give eclipse a gigabyte or more of memory to work with. How the hell is eclipse using that much memory?
Also, most of eclipse's lauded plugins have major stability issues, to the point where you basically can't use them. I find that your average eclipse plugin, even one's included in a common eclipse distribution, will die on basic things like null pointer errors. Haven't these people heard of unit tests? How about *any* kind of testing?
Finally, I generally don't think that Java makes for good desktop applications. Java may be great for the server, but just because I'm *writing* java code, doesn't mean I want to be using java code to write it.
Generally, long running desktop applications should be written in c or c++, and sometimes in python. Java's memory profile is such that desktop applications tend to suck up all available memory, and then crash, or become unresponsive while doing long garbage collections. In comparison c++ always uses the minimal amount of memory, and python is almost optimal since it uses reference counting.
When the eclipse team had to roll it's own widget toolkit, they should have taken that as a hint and written it in c++, where there are numerous widget toolkit's available.
The final problem with eclipse that I see, is that they are turning it into a general platform, that people can munge all of their java code into to write desktop applications as plugins to eclipse. All of these applications just inherit the problems that eclipse has.
If you want to do java development, there are a lot of java editors and java IDE's out there.
On the java java ide front there is:
netbeans (by sun)
intellij (costs money, but is supposed to be the best, so if you work at a company that will pay for it, who cares?)
I can't speak as to whether these java IDE's have solved the memory problem, but they can't possibly be as bad as eclipse.
For native c++ editors, check out slick edit. It supports intellisense and refactoring. It is highly efficient, and can support intellisense and refactoring *without* being used in IDE mode. Instead, you can use it as a light weight editor, while getting the benefits of an IDE in terms of a high level of understanding of the code. It does cost money, but then, who cares?
Re:It's not the "in" opinion.. but.. (Score:3, Insightful)
VIM for the masses (Score:1, Insightful)
I agree (Score:5, Insightful)
Eclipse is the only IDE that I've found that can work across all these scenarios, and leave me with the same IDE across multiple languages. I don't have to worry about remembering the layout of multiple IDEs for each language or OS, and that makes me more productive. I install the plugins that I need (YOXOS, FTW!), and I can drop the eclipse directory on a network share, USB drive, or live CD and have the same environment everywhere I go. Every computer has a JRE installed these days. Also, each summer they do an incredible job of releasing multiple projects on the same day. The built in debugger is great, too. I've yet to find a better way to debug multi-threaded apps. Finally, you can specify, at launch, the memory parameters for the IDE via the normal JRE flags (-xmms, -xmlimit, etc.) if you aren't on such a beefy machine. But then again, if you're developing and debugging any language 'higher' than c/c++ these days, your sanity will depend on having a fairly beefy machine. Especially if you want to have firefox open on one screen and your IDE open in another (although, you can open firefox in Eclipse if you haven't the extra screen real estate).
It's unfortunate that the in crowd, armed with mostly FUD and occasional actual arguments, has decided that Eclipse is 'teh sux0rz'. I've yet to find many people who can put up much of an argument against Eclipse that doesn't center around; "Java is slow" (1996 wants their troll back, modern JITs are nearly as fast as native machine code), "it's ugly" (right, does it work?), "it uses too much memory" (ok, have you bothered to change your JRE memory settings?), "it's a huge download" (without JRE the base download is less than 100 MB), "dependency chasing sucks" (true, have you tried YOXOS?), "I'd prefer emacs" (I prefer vi, but you won't catch me writing or debugging a high level language in it). To each his own, but Eclipse is a great IDE if you give it a shot.