October 12, 2009
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
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
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
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
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
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
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
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
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
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.