[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: What a modern collaboration toolkit looks like
Re: What a modern collaboration toolkit looks like
Tue, 01 Jan 2008 12:43:52 -0700
Gnus/5.11 (Gnus v5.11) Emacs/22.0.990 (gnu/linux)
>>>>> "Miles" == Miles Bader <address@hidden> writes:
Miles> These people apparently treat software as some kind of fashion
Miles> contest. Do you expect us to put any stock in what they say?
I tell all my friends that I work in a fashion industry :-). How else
to explain the long parade of fads and silver bullets, or at least
silver-handled six-shooters? But seriously...
A couple years ago, after using and loving Emacs for 15 years, I moved
all my Java development into Eclipse. I did this despite the facts
that Eclipse's editor is amazingly bad and its UI is clunky and
impossible to customize.
The reason I did this is that Eclipse provides a number of compelling
features which Emacs does not. At least, it does for Java -- for
other programming languages it is not nearly as useful, IME.
* An integrated Java compiler that knows about your whole project.
This has a number of nice implications:
* No more waiting. It compiles while you type. When you save a
file you are ready to run your tests immediately.
* Class browsing, call hierarchy information ("find all callers of
this method"), intelligent completion, documentation and API help
while you type.
* Refactoring. E.g., a simple one is "rename this class". If you
rename into a different package it will update all users, all
import statements, etc. (There are lots of nice refactorings.)
* Quick fix. Certain common problems (warnings and whatnot) can
come with a fix, you click and Eclipse fixes your code.
* Will write the Javadoc "skeleton" for you, so you can just fill in
* A problem view. I loved this. Instead of compiling and then
stepping through errors and warnings, the view shows everything,
is always up-to-date, and is filterable.
* Eclipse knows about projects, and you can easily share settings with
other developers. (This is what inspired my as-yet-unfinished
"project.el" hacks.) This means that getting a new developer
up-and-running is extremely easy.
Combined with the integrated compiler and build setup, usually a
developer can check out a project and immediately have it be built
and be ready to work. You can check in launchers so that common
test or debug invocations are automatically available after
Many features are trivial to restrict to the current project -- the
problem view, searches, browsing, file-name completion. In Emacs
most things are global by default -- you can run a single gdb,
find-tag uses a global tags buffer, etc.
* The version control UI is much friendlier than VC. At least, that
is true as of a couple weeks ago.
Newer versions have bugzilla integration, and task-based ways to
filter what you work on and see ("mylyn" -- I still haven't played
The above is necessarily a brief list. I can go into more detail if
you really want. Basically, for Java, Eclipse changed the way I work.
It pained me to make this move. I love Emacs. But, Emacs doesn't get
the same level of investment, and at the time appeared from the
outside to be dead (no release in years).
None of these features is impossible to implement in Emacs. In fact
many could probably be done by reusing Eclipse's Java compiler.
Another interesting IDE to look at is NetBeans. I've used it a lot
less than I used Eclipse, and it seemed to have fewer killer features.
But I went to JavaOne last year and saw something really interesting
-- every new technology introduced during a keynote came with a
corresponding NetBeans plugin. And, you could get started using that
technology *immediately* by going to some online NetBeans repository
(accessible directly in the IDE) and downloading the plugin.
This is, more or less, where ELPA came from. The idea is simple --
your IDE won't ever contain absolutely everything, so make it trivial
to fetch and install helpful packages. (Eclipse also has a plugin
downloader, though it is pretty bad.)
Anyway, the bar for a programming editor is much higher now than when
I started using Emacs. Nowadays intelligent completion, API help,
browsing, and refactoring are the baseline. Emacs does some of these
in some modes -- elisp is the best example; lisp-complete-symbol and
eldoc are quite nice -- but for most modes this stuff is either
missing, or the defaults are wrong.
I hope you don't mind that I don't enumerate Emacs' many advantages.
There are tons of them. Emacs is very, very strong at the mechanics
of editing, and it is very simple to extend (lisp may be weird or
whatever, but even a trivial Eclipse plugin is really hard). However,
while Emacs rocks at these things, the IDEs have been working hard to
intelligently analyze source and apply this understanding in useful
Re: What a modern collaboration toolkit looks like, Romain Francoise, 2008/01/01
Re: What a modern collaboration toolkit looks like,
Tom Tromey <=
Re: What a modern collaboration toolkit looks like, Richard Stallman, 2008/01/02
Re: What a modern collaboration toolkit looks like, Alan Mackenzie, 2008/01/01
- Re: What a modern collaboration toolkit looks like, (continued)
- Re: What a modern collaboration toolkit looks like, Tassilo Horn, 2008/01/02
- Re: What a modern collaboration toolkit looks like, John S. Yates, Jr., 2008/01/02
- Re: What a modern collaboration toolkit looks like, Eric S. Raymond, 2008/01/02
- Re: What a modern collaboration toolkit looks like, Richard Stallman, 2008/01/03
- Re: What a modern collaboration toolkit looks like, tomas, 2008/01/02
- Re: What a modern collaboration toolkit looks like, Richard Stallman, 2008/01/02