dmd support for IDEs

[Ary Borenszweig]

BLS wrote:
> On 12/10/2009 11:41, breezes wrote:
>> 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. :-)
>>
>> A lot of people like me have been waiting for a good IDE for D for a 
>> long time. In the field of IDE of D, Descent has already have a good 
>> baseline. So I think the community should put more effort in make 
>> Descent better, other than create another IDE.
>>
>> For this reason, I think Ary Borenszweig's opinion on in which way can 
>> dmd help in building a better IDE may be more valuable than Water's, 
>> for he is the author of the currently most advanced IDE of D.
>>
>> Sorry for my poor English.
> 
> What I definitely don't like is that Decent is just a Eclipse plugin. I 
> don't want a Java IDE plus D.
> I would prefer a pure D IDE.
> 
> Being a Netbeans guy but I am pretty sure that it is possible to remove 
> all the Java related things. side effects : less bloat more speed.
> 
> my 2 euro cents

No, but that's the good thing about it: it's just a plugin. You don't 
need the Java IDE to run Descent.

Michal Minich wrote somewhere else:

---
You can try to download just bare Eclipse platform (which is just text 
editor) and install descent into it using Eclipse software updates. It 
starts up faster than C or Java version Eclipse and there is only D 
related stuff in the UI.

http://download.eclipse.org/eclipse/downloads/drops/R-3.5.1-200909170800/index.php
Under "Platform runtime binary"
---

I tried it and it's true, it feels much lighter this way and you don't a 
lot of bloat in menus and other things.