October 11, 2009
Leandro Lucarella wrote:
> I think you've got that answer because they are not using D alread. When
> they start using D, they will start complaining about Phobos vs. Tango,
> debugger support, librararies, bugs, etc. ;) (maybe not DMD being GPL
> though, even when I think it's important).


I've heard this from D fans as well, who are unable to get D adopted at work because of the lack of IDE.
October 11, 2009
Walter Bright, el 11 de octubre a las 12:40 me escribiste:
> Leandro Lucarella wrote:
> >I think you've got that answer because they are not using D alread. When they start using D, they will start complaining about Phobos vs. Tango, debugger support, librararies, bugs, etc. ;) (maybe not DMD being GPL though, even when I think it's important).
> 
> I've heard this from D fans as well, who are unable to get D adopted at work because of the lack of IDE.

I can't because of the other issues =(

(we don't use an "IDE" at my work, not at least if you don't consider VIM
an IDE =)

-- 
Leandro Lucarella (AKA luca)                      http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Soñé que tenia un caballo
Que me trataba mejor que vos
Tenia tan buena onda con ella
Era mi yegua, mucho mas que vos
October 11, 2009
On 10/11/09 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.

I use it almost at a daily base and it works great. I can't remember the last time it cashed.

> 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. :-)

October 11, 2009
On 10/11/09 16:32, Denis Koroskin wrote:
> On Sun, 11 Oct 2009 05:19:56 +0400, Walter Bright
> <newshound1@digitalmars.com> 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.
>>
>> 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? Intellisense
>> (Microsoft's word for autocompletion).
>>
>> 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.
>>
>> The nice thing about an xml file is while D is relatively easy to
>> parse, xml is trivial. Furthermore, an xml format would be fairly
>> robust in the face of changes to D syntax.
>>
>> What do you think?
>
> I believe it won't work. It will always be slow and incomplete.
>
> Instead, I would make it easier to embed DMD into an IDE: separate DMDFE
> from DMDBE, fix memory leaks, remove all the static data (so that code
> would be re-intrable and it could work in different threads in
> parallel), move most of DMD code into a DLL so that an IDE could
> dynamically link with it and whatever it pleases with the source code.
>
> In fact, that's what I do right now.
>
> I'm writing my own D IDE in my spare time (in D, of course). I already
> made a lot of progress and now it's time to start implementing source
> code analysis.
>
> First thing I did is I made complete D bindings for C++ code. It worked
> out quite well but it was leaking so badly that I dropped it.
>
> Instead, I started porting DMD entirely to D (except the backend, of
> course), and I already got some great results. A few simple programs
> compile and produce byte-perfect binaries. It's still in its early
> stages and there is a lot of work to do, but it will be finished soon
> (hopefully). It could probably become a part of an official
> distribution, eventually. :)
>
> If anyone is interested and is willing to test and/or help, I will
> gladly share my code.

Sounds interesting, put it online somewhere.
October 11, 2009
On 10/11/09 16:38, BLS wrote:
> On 11/10/2009 03:19, 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.
>>
>> 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? Intellisense (Microsoft's
>> word for autocompletion).
>>
>> 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.
>>
>> The nice thing about an xml file is while D is relatively easy to parse,
>> xml is trivial. Furthermore, an xml format would be fairly robust in the
>> face of changes to D syntax.
>>
>> What do you think?
>
> FANTASTIC! Give it a go.
>
> Despite the intention to support a D IDE ...
> I would make sense to establish this feature in D1 too.
> Imagine XML2D which may help to port D1 code to D2.
>
> I would further suggest to consider to output to Oracle Berkeley DB XML ..
> Having an XQuery-based access to D-sources.. I guess you can imagine
> what this could mean.
>
> There are a couple of D IDEs around.
> I think what people mean with there is no D IDE is simply : "We want a
> MS Visual Studio like IDE as part of the D tool chain" One download,
> that's it.
> I agree. But we need a platform independent IDE.
>
> Our Options :
> 1) Force Decent.. (Java/SWT)

I think this the our best option now

> 2) Use gtkD, create the IDE in D. (the only usable platform independent
> GUI atm.)
>
> 3) Use QT and C++. Let's re-use and adapt QT Creator.
>
> Having QT as standard GUI toolkit for D means that we can also reuse the
> QT Designer.

As far as I know neither Qt(d) or gtkD uses native controls on platforms other than linux, which to me is unacceptable. The look especially on mac.

4)
Port entire eclipse to D, Frank Benoit (who started DWT, the tango version) was thinking of this.

> Bjoern
>

October 11, 2009
On 10/11/09 21:38, Walter Bright wrote:
> Ary Borenszweig wrote:
>> Walter Bright wrote:
>>> Denis Koroskin wrote:
>>>> In fact, that's what I do right now.
>>>
>>> I think that's great. But it requires a lot of work (as of course you
>>> know).
>>
>> Good things require a lot of work. :)
>
> Of course. But getting something done and available in a short amount of
> time is also good!
>
> For example, some people say to me "why should I use D, when C++0x
> solves my issues with C++?"
>
> And I point out "how many more years are you willing to wait for C++0x,
> when D is here now?"
>
> [Setting aside for the moment the issue of whether C++0x really is
> better than D or not!]
>
> The point is, good enough now gets us further down the road of getting a
> user base large enough to justify the effort for a more comprehensive
> solution.

I think descent is really good now.

> For example, if I have many miles to commute to work, the best choice is
> a car. But if I can't afford a car, or am too young to drive, a bike at
> least gets me there. Before I was 16 and could drive, a bike was very
> liberating for me, I rode it everywhere.

October 11, 2009
On Mon, 12 Oct 2009 00:36:01 +0400, Jacob Carlborg <doob@me.com> wrote:

> 4)
> Port entire eclipse to D, Frank Benoit (who started DWT, the tango version) was thinking of this.
>
>> Bjoern
>>
>

What's the benefit? I believe it'll become even slower. Much slower.
October 11, 2009
On 10/11/09 20:58, Yigal Chripun wrote:
> 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?

Frank Benoit (who started DWT, the tango version) was think about this. Quite a big part is already ported, SWT, JFace, Forms, OSGI and so on, see: http://hg.dsource.org/projects/dwt2/file/88652073d1c2/ .

I think one of the biggest challenge to port is class loading, dynamic libraries could work for this but we all know how well they work on windows.
October 11, 2009
"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:hasodv$dgl$3@digitalmars.com...
> Nick Sabalausky wrote:
>> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:has92u$1vum$1@digitalmars.com...
>>> Lutger wrote:
>>>> What about file/line/column of the symbol? Is this much work / hard work to add?
>>> file/line of course, but I don't see a point to column.
>>
>> So the IDE knows where it is and can actually do things with it, instead of just knowing "Well, it's somewhere around here-ish."
>
> And what should the tab size be? >:o)
>

No need to worry about that. It should just be counted as one character. Granted, that does mean it wouldn't really be "column" in a strict sense, but it would be very useful.


October 11, 2009
On 10/11/09 22:37, Denis Koroskin wrote:
> On Mon, 12 Oct 2009 00:36:01 +0400, Jacob Carlborg <doob@me.com> wrote:
>
>> 4)
>> Port entire eclipse to D, Frank Benoit (who started DWT, the tango
>> version) was thinking of this.
>>
>>> Bjoern
>>>
>>
>
> What's the benefit? I believe it'll become even slower. Much slower.

Maybe we could try to slim it down, remove things that aren't needed.