On 11/10/2009 15:23, Ary Borenszweig wrote:
Walter Bright wrote:
In my discussions with companies about adopting D, the major barrier
that comes up over and over isn't Tango vs Phobos, dmd being GPL,
debugger support, libraries, bugs, etc., although those are important.
It's the IDE.
So, while I'm not going to be writing an IDE, I figure that dmd can
help. dmd already puts out .doc and .di files. How about putting out
an xml file giving all the information needed for an IDE to implement
autocompletion? There'd be one .xml file generated per .d source file.
What do you think?
What I think is that even with an xml representing the parse tree (maybe
with some semantic stuff resolved) it'll be still incomplete for a real
IDE (the kind of thing users expect from an IDE). You can see this
video, for example:
http://www.youtube.com/watch?v=KQbTT605ags
So you have:
---
module one;
class Foo(T) {
static if (is(T == class)) {
T property;
} else {
T someMethod() { return T.init; }
}
mixin(guessWhat!(T)());
}
---
You want to define an xml for that module that'll help IDEs. Can you
think what it'll look like?
Now the user writes in another module:
class Bar {
}
void x() {
auto foo = new Foo!(Bar)();
foo. <-- what does the IDE do here?
}
Now, the correct thing for the IDE to do is to suggest the field "Bar
property". How can the IDE do that just with an xml? It can't. It need
to perform some kind of semantic anlysis to Foo's argument to see if
it's a class, match the static if in the template, replace template
parameters, etc. It also needs to evaluate the string mixin.
Of course you could say "Bah, just show all the declarations inside the
template in the autocomplete", but that's wrong. That'll lead to files
that don't compile. You could ommit supporting autocompletion or other
nice features, but that's exactly the big features of D. If you don't
support that then it's like using Java or C# from within the IDE: you
could use the advanced features but the IDE won't help you. And in your
discussions with companies adopting D, I'm sure they were talking about
great IDEs like JDT Eclipse or Visual Studio, not just some tool that
helps you a little but not anymore when things get interesting.
Oh, and you need to have some kind of semantic analysis to know the type
of "auto foo". Again, maybe the IDE can be dummy and see "auto foo = new
Foo!(Bar)" and say "ok, foo's type is Foo!(Bar)", but then you have:
auto b = foo.property;
b. <-- and here?
// remember "property" is templated and depends on static analysis
// or the IDE could need to resolve alias this or other things
So... my opinion (like some others, I see) is to either ask things to
the compiler directly (but here the compiler lacks some info, like exact
source range positions), or to have a compiler (not a full-blown one,
just the front-end) built into the IDE, and that's what Descent is.
Unfortunately Descent is sometimes slow, sometimes buggy, but that's
normal: just a few people develop and maintain it (so I can see a
similarity with dmd here, where each day I see two or three new bugs
reported). If more people were into it, more unit tests were written
into it and, most of all, more people would use it, it'll get better.
Another problem that people see in Descent (maybe also JDT Eclipse and
Visual Studio0 is that it's huge, it consumes a lot of memory and they
don't want to open a huge tool just to hack some lines. My answer is:
memory performance can be improved (but not a lot), but since an IDE is
a huge tool it requires a lof from the computer. And an IDE is not meant
to be used to hack some lines, it's meant to help you write big project,
huge projects without getting lost in the amount of code.
So my bet would be to start supporting an existing IDE that integrates a
compiler into it. Updating it is easy: just port the diffs between DMD
versions. It's a huge job for one or two people, but if a lot of people
were involved it's not that much. Of course I'd recommend you to try
Descent since I'm one of it's creators and I do believe it can get
pretty good. :-)
well put.
btw, given that we have a port of SWT for D, how hard would it be to
create our own native D version of eclipse?
