Jacob Carlborg wrote:
On 10/11/09 11:56, Frank Benoit wrote:
Walter Bright schrieb:
They say that the productivity gains of D's improvements are
overbalanced by the loss of productivity by moving away from an IDE. And
what is it about an IDE that is so productive?
If you use Eclipse for Java, you have:
- Debugger in place
- Automatic builder, compile on save
* Jump to line from error list
* Jump to declaration
- Show JavaDoc in tooltip, even in autocompletion
- Show hierarchy tree
- Autocompletion
- Quick assist, e.g.
- assign ctor parameter to new field
- extract selected text into local variable
- Mark source portion, extract to method, the IDE evaluates the
needed
parameters and return value
- ...
There is so much more. But the main thing is, you are not only able to
use grep and friends on the pure text level. With an IDE you have
semantic support. This makes refactoring your code so much easier. You
can say "rename this method" and it works, all references to this method
are also altered. "Move this inner class to a top level class in that
package", "Derive from that class, yes add the needed ctors". There is
even an API to automate refactorings.
I think Descent is the right way. But here, a port of DMD is directly
integrated into the plugin. To put more manpower in this project would
be the best way imo.
I completely agree. I don't know if it would be better to have the parts
of dmd that descent needs in a separate library to avoid porting half of
dmd to java.
Which is why i suggested that next to the XML/JSON output there can be
an API for plugins like descent to build on top of, instead of forking
the entire compiler source making it near impossible to keep up with
changes.
In my opinion, more manpower needs to be put in dmd itself so more third
party programs and plugins can use it directly, the goal is to make dmd
more powerful while supporting more usages.
