March 10, 2010
Ellery Newcomer wrote:
> On 03/09/2010 06:15 PM, Walter Bright wrote:
>> Ellery Newcomer wrote:
>>> I hate the restriction on modules with static constructors and cyclic
>>> dependencies. IMO it's the most patronizing 'feature' D has.
>>
>> I understand, but the alternative is the essentially random order of
>> execution that C++ has.
> 
> Would you contend that the alternative that I showed above is not random order?

Doesn't look random to me.

By "random" I mean it is implementation-defined, and in practice it depends on the order the linker assembles things in, which is not at all easily controlled.
March 10, 2010
bearophile wrote:

> Walter Bright:
>>but the priority right now is finalizing D2.<
>
> Having a bit of roadmap can't hurt, it can even help. So, what are the missing things?
>
> Bye,
> bearophile

There is a reasonably up-to-date community driven roadmap. Don has done a lot of work on it.

http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#FutureDirections
March 10, 2010
On 10.03.2010 0:57, Walter Bright wrote:
>
> The circular module thing is usually a result of static constructors in
> each of two modules that import each other. There are many solutions to
> this, such as switching to lazy initialization, moving the
> initializations to a 3rd module, having the initialization done by a
> function called explicitly from main(), etc.
>
>

Mixed-in state that requires static initialization is a problem. Neither of the solutions you have listed seems to work well in that scenario:

1. Access to the lazily initialized data must be synchronized, which is not always a way to go.

2. A third module cannot be used. At least, we haven't been able to figure out how to do that. Probably, something could be hacked up if this bug (feature) is fixed http://d.puremagic.com/issues/show_bug.cgi?id=2671

3. Forcing the user to initialize each mixed-in piece manually is a potential source of grievance.
March 10, 2010
Max Samukha wrote:
> 2. A third module cannot be used. At least, we haven't been able to figure out how to do that. Probably, something could be hacked up if this bug (feature) is fixed http://d.puremagic.com/issues/show_bug.cgi?id=2671

Thanks, I'll have a look at it.
March 10, 2010
Walter Bright wrote:
> Max Samukha wrote:
>> 2. A third module cannot be used. At least, we haven't been able to figure out how to do that. Probably, something could be hacked up if this bug (feature) is fixed http://d.puremagic.com/issues/show_bug.cgi?id=2671
> 
> Thanks, I'll have a look at it.

The example in the bug report works on D1 and D2. I cannot reproduce the error. I marked it as "worksforme"; if I've got the test case wrong please reopen it.
March 10, 2010
Justin Johansson wrote:
> Walter Bright Wrote:
> 
>> Justin Johansson wrote:
>>> Having spent six months developing a significant app in D only to find impediments to
>>> practical completion of the project and ultimate deployment,
>> Which ones did you find to be blocking?
> 
> (My time zone is way different to yours and gotta dash to work soon so will have to be brief).
> 
> (Comments in relation to D1)
> 
> #4 The performance of the IDE that I was using (Descent under Eclipse) did not scale
> very well with large source files.  Tried a few other development tools but found Descent
> to be overall the best but, like I say, not adequate at scaling in a large project.
> Sure this is not a D language problem per se but a practical issue that is still likely to
> put some users off.

Can you send me an example of such large source file?
March 10, 2010
On 3/10/10 13:55, Ary Borenszweig wrote:
> Justin Johansson wrote:
>> Walter Bright Wrote:
>>
>>> Justin Johansson wrote:
>>>> Having spent six months developing a significant app in D only to
>>>> find impediments to
>>>> practical completion of the project and ultimate deployment,
>>> Which ones did you find to be blocking?
>>
>> (My time zone is way different to yours and gotta dash to work soon so
>> will have to be brief).
>>
>> (Comments in relation to D1)
>>
>> #4 The performance of the IDE that I was using (Descent under Eclipse)
>> did not scale
>> very well with large source files. Tried a few other development tools
>> but found Descent
>> to be overall the best but, like I say, not adequate at scaling in a
>> large project.
>> Sure this is not a D language problem per se but a practical issue
>> that is still likely to
>> put some users off.
>
> Can you send me an example of such large source file?

I usually have problems with this file when it contains errors: http://hg.dsource.org/projects/dwt-mac/file/969e7de37c3d/dwt/internal/cocoa/OS.d 


It usually contains errors after a merge of SWT when I'm updating DWT to a new version. I never have problems with the original java file.
March 10, 2010
On 3/9/10 22:35, Justin Johansson wrote:
> Walter Bright Wrote:
>
>> Justin Johansson wrote:
>>> Having spent six months developing a significant app in D only to find impediments to
>>> practical completion of the project and ultimate deployment,
>>
>> Which ones did you find to be blocking?
>
> (My time zone is way different to yours and gotta dash to work soon so will have to be brief).
>
> (Comments in relation to D1)
>
> #4 The performance of the IDE that I was using (Descent under Eclipse) did not scale
> very well with large source files.  Tried a few other development tools but found Descent
> to be overall the best but, like I say, not adequate at scaling in a large project.
> Sure this is not a D language problem per se but a practical issue that is still likely to
> put some users off.

I also have this problem with some of my D files. But on the other hand I've never seen a tool/IDE for C++ that can do to what descent does. I.e. showing both syntax and semantic errors as you type.

> Cheers,
>
> Justin Johansson
>

March 10, 2010
On 3/9/10 23:57, Walter Bright wrote:
> Justin Johansson wrote:
>> The #1 show-stopper for me was lack of shared object (.so) support
>> under Linux; virtually
>> mandated by my audience (Apache/LAMP). (A workaround like FastCGI is
>> simply not
>> appealing to customers.) This topic discussed many times before on
>> this NG.
>
> I know this is a big problem and I know it's been discussed a lot, I
> just wanted to be sure what was stopping you.
>
>
>> #2 significant deterioration of D's GC under high working dataset
>> volume. The GC did
>> not seem to scale very well. Since moving back to C++ I've implemented
>> my own
>> memory management technique (note I said memory management not
>> *automatic* GC).
>> One of the biggest reasons for using D in the first place (automatic
>> GC) no longer held for me.
>> This topic also discussed much before on this NG.
>
> It is possible to do your own memory management with D.
>
> There've been a lot of proposals for improved gc, but not really anyone
> willing to step up and do the work. On the plus side, D's gc has proven
> to be remarkably robust and reliable. It's a solid, if pedestrian,
> implementation.
>
>
>> #3 problems with circular module references. I forget some of the
>> detail but think, if I
>> recall correctly, that it was to do with static class members so had
>> to pull a lot of source
>> code into one big file .. then leading to problem #4
>
> The circular module thing is usually a result of static constructors in
> each of two modules that import each other. There are many solutions to
> this, such as switching to lazy initialization, moving the
> initializations to a 3rd module, having the initialization done by a
> function called explicitly from main(), etc.
>

I've always wonder why that is. I mean if I put an empty static constructor in two modules and they import each other I get a circular reference error. Usually when I use static constructors they don't depend on the order of each other. Can't this be fixed if the static constructors don't depend on each other?

March 10, 2010
On 3/10/10 01:15, Walter Bright wrote:
> Ellery Newcomer wrote:
>> I hate the restriction on modules with static constructors and cyclic
>> dependencies. IMO it's the most patronizing 'feature' D has.
>
> I understand, but the alternative is the essentially random order of
> execution that C++ has.

How does Java handle this ?