View mode: basic / threaded / horizontal-split · Log in · Help
October 12, 2009
Re: dmd support for IDEs
Sun, 11 Oct 2009 16:07:44 -0300, Leandro Lucarella thusly wrote:

> Walter Bright, el 10 de octubre a las 18:19 me escribiste:
>> 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).
> 
> 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).

What can I say, the larger the enterprise, the larger the expectations 
and need for stability. You can try it yourself, any Java 1.4 code from 
2003 can be compiled, debugged, profiled etc. nicely with the most recent 
version of jdk and 3rd party tools. It's also nicely compatible with new 
code. OTOH take some D 1.0 code from 2003 (e.g. the free dool/dui or aba 
games code available online) and try to do *something* with it. Basically 
nothing works. You even have problems with new code as some project 
depends on a specific svn version of tango trunk. There is a lot to be 
done before D is ready for large scale enterprise use.
October 12, 2009
Re: dmd support for IDEs
Sun, 11 Oct 2009 17:01:03 -0400, Nick Sabalausky thusly wrote:

> "language_fan" <foo@bar.com.invalid> wrote in message
> news:hasd5u$1fgu$1@digitalmars.com...
>>
>> Well since there is already a project working on an Eclipse plugin, I
>> see little use for other IDEs at the moment. The D community is rather
>> small and only a small amount of people are capable of developing and
>> willing to donate their free time on free IDE development (commercial
>> IDEs have small potential now that
>> Netbeans/Eclipse/IntelliJ/KDevelop/Visual Studio dominate the market).
>> So why not concentrate on fixing the spec and fixing compiler bugs
>> instead of building a modest IDE support no one will use?
> 
> Any editor that is less responsive than notepad is useless to me, and
> I'm far from alone on that. Thus, we don't go anywhere near Eclipse,
> VS.NET, or anything along those lines (bunch of bloated garbage...and
> probably designed to get developers to buy fancier hardware and thus end
> up develop apps that require their users to buy fancier hardware).

Fine, if you are happy with your productivity. For me it was a natural 
choice. I started with notepad like editors, then moved to "programmer's 
editors" like crimson editor and jedit, soon discovered vim and emacs, 
and finally have settled down on Eclipse, Netbeans, Visual Studio, and 
IntelliJ IDEA. The productivity boost is enormous. "Practical" languages 
have lots of boiler-plate, and I can easily generate hundreds of lines of 
code with a couple of key combinations or mouse clicks. Another killer 
feature is the "intellisense" stuff. Having the ability to see a) 
inferred type b) integrated html rendered javadoc c) type correct class 
members etc. saves me hours of work time per day. YMMV
October 12, 2009
Re: OT: GUI Libraries
Sun, 11 Oct 2009 22:54:39 -0400, Chad J thusly wrote:

> Jeremie Pelletier wrote:
> 
>> We can make programs that switch between GUI backends, most just don't
>> go in that direction. Its as easy as graphics engines having GL and DX
>> backends for their render system.

Web 2.0 toolkits are platform neutral. You can define your own GUI with 
javascript & html & css. The interfaces (ajax, javascript, css, html, 
xml) have all been standardized. The objects on the GUI also do not waste 
low level handles like the traditional GUI toolkits do. I am sure that 
more locally usable Web 2.0 desktop applications are coming in the next 
few years.
October 12, 2009
Re: dmd support for IDEs
On 10/12/09 02:08, Jeremie Pelletier wrote:
> Lutger wrote:
>> Jacob Carlborg wrote:
>> ...
>>> 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.
>>
>> Qt used to try and look like native controls, but now it uses them
>> directly.
>
> It has pros and cons, Firefox too has the native look and feel without
> using the native controls, so it saves on the overhead of tons of GDI
> handles and can render the entire GUI in cairo.

In the Mac version for a long time they used the older tabs from Mac OS 
X 10.4 or even older. That's the problem not using native controls, if 
the operating system change them it's a lot of more work to update your 
application.
October 12, 2009
Re: dmd support for IDEs
On 10/12/09 04:14, Chad J wrote:
> Jeremie Pelletier wrote:
>> Lutger wrote:
>>> Jacob Carlborg wrote:
>>> ...
>>>> 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.
>>>
>>> Qt used to try and look like native controls, but now it uses them
>>> directly.
>>
>> It has pros and cons, Firefox too has the native look and feel without
>> using the native controls, so it saves on the overhead of tons of GDI
>> handles and can render the entire GUI in cairo.
>
> I actually rather dislike GTK from a user standpoint.  It doesn't mesh
> well at all on my KDE linux setup.  The file dialog is also a frequent
> source of annoyance, as it is different then everything else and seems
> to want to fight with me.  Qt is much better at these things.
>
> Too bad we can't just make programs switch between GUI backends at will ;)

Why not have a GUI toolkit available on almost all platforms that uses 
native controls just like DWT?
October 12, 2009
Re: dmd support for IDEs
Mon, 12 Oct 2009 14:02:11 +0200, Jacob Carlborg thusly wrote:

> On 10/12/09 04:14, Chad J wrote:
>> Too bad we can't just make programs switch between GUI backends at will
>> ;)
> 
> Why not have a GUI toolkit available on almost all platforms that uses
> native controls just like DWT?

The list of native platforms SWT supports is this:

Win32
 WPF (under development)
AIX, FreeBSD, Linux, HP-UX, Solaris: 
 Motif
 GTK+
Mac OS X: 
 Carbon
 Cocoa
QNX Photon
Pocket PC

As a FLTK2, Qt 3.x, Qt 4.x, Swing, and (forked) Harmonia user I fail to 
see how SWT is more native than the ones I develop for. All SWT 
applications look weird, unthemed, and have horrible usability issues in 
the file open/save dialogs. DWT brings another level of cruft above the 
"lightweight" SWT and performs badly.
October 12, 2009
Re: dmd support for IDEs
Sat, 10 Oct 2009 18:19:56 -0700, Walter Bright thusly 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?

Another point not mentioned here is that modern IDEs use incremental and 
interactive compilation model. The compiler should be run as a persistent 
background process and parsing should happen perhaps on the level of the 
current scope. Re-compiling a million line project after each key stroke 
simply makes no sense. Even compiling the current module once per key 
stroke is too slow.

Specifying an intermediate json/xml file format is a huge task 
considering the amount of language constructs, types etc. available in D.

I'm all for good tool support but as many have already mentioned, the 
support would only bring marginal improvements to small scale tools like 
vim and emacs. Usually small scale D projects (< 10000 lines of code) are 
written with those tools (feel free to prove me wrong). These are not the 
kinds of projects large enterprises would use D for, they use scripting 
languages for smaller tasks. Thus the overall improvement is minimal. 
Spending the time on critical compiler bugs on the other hand would help 
everyone in the community.
October 12, 2009
Re: dmd support for IDEs
Jacob Carlborg schrieb:
> 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/ .

Sorry, OSGi is just dummy, to make other stuff compile.
October 12, 2009
Re: dmd support for IDEs
On Sun, 11 Oct 2009 09:32:32 -0500, Denis Koroskin <2korden@gmail.com>  
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.

I would like it if this went open so I could examine it and possibly  
contribute to it. I have wanted to do something like this, but all I have  
started so far is a GUI toolkit. I am new to D so I have not spent much  
time on it yet. It would be nice to be able to work on something more  
developed.

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
October 12, 2009
Re: dmd support for IDEs
language_fan wrote:
> Sun, 11 Oct 2009 09:39:32 -0500, Ellery Newcomer thusly wrote:
> 
>> Denis Koroskin wrote:
>>> On Sun, 11 Oct 2009 05:19:56 +0400, Walter Bright
>>> <newshound1@digitalmars.com> wrote:
>>>
>>> If anyone is interested and is willing to test and/or help, I will
>>> gladly share my code.
>> Oooo.. You should put that on dsource or somewhere. Hacking D sounds
>> like a lot more fun than hacking C++. I wouldn't mind helping out on
>> this one.
> 
> Wow, I am pretty sure I have already seen a D port of dmd on dsource. Was 
> there a good reason to start yet another port of it?

Maybe learning, porting a library or application from a language to 
another is a great way to learn about it inside out. I used to do that a 
lot too.
8 9 10 11 12 13 14 15 16
Top | Discussion index | About this forum | D home