Jeff Nowakowski wrote:
> On 08/04/2010 09:22 PM, Andrei Alexandrescu wrote:
>>
>> Walter is more silent than usual because he's working very hard on the
>> 64-bit compiler. He hopes to have one by the end of this month. His next
>> big goal is shared library support.
> 
> While those are both important, isn't it even more important to have the existing 32-bit implementation complete? How can you showcase a language that's incomplete and buggy? Can't both those features wait until after D2 is considered polished enough to be released?
> 
> I keep seeing reports from people running into bugs, unfinished features, and incomplete documentation. There's no end in sight, either, yet a book has been released and the language is promoted as if it were a finished product.

I've been deferring adding 64 bit support for years. Not having it is the biggest barrier to the adoption of D there is right now.

Wed, 04 Aug 2010 20:22:09 -0500, Andrei Alexandrescu wrote:

> On 08/04/2010 07:25 PM, Jeff Nowakowski wrote:
>> On 08/04/2010 05:16 PM, Robert Clipsham wrote:
>>>
>>> I know of several large apps written in D, they're all D1/Tango.
>>
>> The incomplete state of D2 has to be the most embarrassing question that could have been asked at Andrei's talk, but then you'd have to be familiar with D to ask that question. Andrei likes to talk about presentations showing only what's good, but he gave a whole talk about an incomplete language while hawking his book for said language, but made no mention of D1 vs D2.
>>
>> People often ask for a status, but there never seems to be good answers. Where's the roadmap? What's being worked on? What's left to fix? Is there a release date that's being worked towards? It used to coincide with the release of Andrei's book, but that has come and gone.
> 
> Walter is more silent than usual because he's working very hard on the 64-bit compiler. He hopes to have one by the end of this month. His next big goal is shared library support.

Ok, Walter is working on a 64-bit compiler, then on the shared library support. That's great. But many of us would like to know who is

 * managing the communication with the user community
 * managing the communication with the language/compiler developers
 * managing the bugfixes to the spec
 * managing the compiler bugfix release (minor version) process
 * managing the language development debate
 * coordinating the future language development (roadmap page of the trac)
 * managing the public relations with the people outside the core
community

It seems Walter wants to be a lonely wolf. Nobody else is allowed to do anything listed above unless you're Andrei. There are no managers, we only have experts working with their favorite features and no communication exists between these persons or the community.

On 08/05/2010 01:23 PM, retard wrote:
> Wed, 04 Aug 2010 20:22:09 -0500, Andrei Alexandrescu wrote:
>
>> On 08/04/2010 07:25 PM, Jeff Nowakowski wrote:
>>> On 08/04/2010 05:16 PM, Robert Clipsham wrote:
>>>>
>>>> I know of several large apps written in D, they're all D1/Tango.
>>>
>>> The incomplete state of D2 has to be the most embarrassing question
>>> that could have been asked at Andrei's talk, but then you'd have to be
>>> familiar with D to ask that question. Andrei likes to talk about
>>> presentations showing only what's good, but he gave a whole talk about
>>> an incomplete language while hawking his book for said language, but
>>> made no mention of D1 vs D2.
>>>
>>> People often ask for a status, but there never seems to be good
>>> answers. Where's the roadmap? What's being worked on? What's left to
>>> fix? Is there a release date that's being worked towards? It used to
>>> coincide with the release of Andrei's book, but that has come and gone.
>>
>> Walter is more silent than usual because he's working very hard on the
>> 64-bit compiler. He hopes to have one by the end of this month. His next
>> big goal is shared library support.
>
> Ok, Walter is working on a 64-bit compiler, then on the shared library
> support. That's great. But many of us would like to know who is
>
>   * managing the communication with the user community
>   * managing the communication with the language/compiler developers
>   * managing the bugfixes to the spec
>   * managing the compiler bugfix release (minor version) process
>   * managing the language development debate
>   * coordinating the future language development (roadmap page of the trac)
>   * managing the public relations with the people outside the core
> community
>
> It seems Walter wants to be a lonely wolf. Nobody else is allowed to do
> anything listed above unless you're Andrei. There are no managers, we
> only have experts working with their favorite features and no
> communication exists between these persons or the community.

I think this is a gross misrepresentation. Are you sure you're not forgetting a lot of contributors? If anything, the trend is toward opening the doors to more, not less people.

Andrei

Thu, 05 Aug 2010 13:31:18 -0500, Andrei Alexandrescu wrote:

> On 08/05/2010 01:23 PM, retard wrote:
>> Wed, 04 Aug 2010 20:22:09 -0500, Andrei Alexandrescu wrote:
>>
>>> On 08/04/2010 07:25 PM, Jeff Nowakowski wrote:
>>>> On 08/04/2010 05:16 PM, Robert Clipsham wrote:
>>>>>
>>>>> I know of several large apps written in D, they're all D1/Tango.
>>>>
>>>> The incomplete state of D2 has to be the most embarrassing question that could have been asked at Andrei's talk, but then you'd have to be familiar with D to ask that question. Andrei likes to talk about presentations showing only what's good, but he gave a whole talk about an incomplete language while hawking his book for said language, but made no mention of D1 vs D2.
>>>>
>>>> People often ask for a status, but there never seems to be good answers. Where's the roadmap? What's being worked on? What's left to fix? Is there a release date that's being worked towards? It used to coincide with the release of Andrei's book, but that has come and gone.
>>>
>>> Walter is more silent than usual because he's working very hard on the 64-bit compiler. He hopes to have one by the end of this month. His next big goal is shared library support.
>>
>> Ok, Walter is working on a 64-bit compiler, then on the shared library support. That's great. But many of us would like to know who is
>>
>>   * managing the communication with the user community * managing the
>>   communication with the language/compiler developers * managing the
>>   bugfixes to the spec
>>   * managing the compiler bugfix release (minor version) process *
>>   managing the language development debate * coordinating the future
>>   language development (roadmap page of the trac) * managing the public
>>   relations with the people outside the core
>> community
>>
>> It seems Walter wants to be a lonely wolf. Nobody else is allowed to do anything listed above unless you're Andrei. There are no managers, we only have experts working with their favorite features and no communication exists between these persons or the community.
> 
> I think this is a gross misrepresentation. Are you sure you're not forgetting a lot of contributors? If anything, the trend is toward opening the doors to more, not less people.

I understood that all the contributors are waiting for the decision of a single person. Walter needs to review all compiler patches, he needs to review all patches to the spec, he needs to defend D on reddit, newsgroups, and all other forums. He handles the whole release process. He doesn't tell anything about future directions so nobody knows about them.

The management model doesn't scale when you get more and more contributors. At some point Walter won't have enough time to review all contributions even if it didn't do anything else.

For example now that he is focusing on 64-bit support, all discussion about rewriting the spec, fixing bugs, improving the other parts of the toolchain, or developing the language further (D 2.1 or 3.0) has stalled. Many people have asked bearophile to stop discussing new language features because it takes away too much valuable time from Walter. Something is wrong here.

retard wrote:
> Ok, Walter is working on a 64-bit compiler, then on the shared library support. That's great. But many of us would like to know who is
> 
>  * managing the communication with the user community
>  * managing the communication with the language/compiler developers
>  * managing the bugfixes to the spec
>  * managing the compiler bugfix release (minor version) process
>  * managing the language development debate
>  * coordinating the future language development (roadmap page of the trac)
>  * managing the public relations with the people outside the core community
> 
> It seems Walter wants to be a lonely wolf. Nobody else is allowed to do anything listed above unless you're Andrei. There are no managers, we only have experts working with their favorite features and no communication exists between these persons or the community.

There are quite a few people actively contributing to all of the above. Perhaps you don't monitor the D mailing lists where a lot of this activity is going on.

If there's a particular one you want to contribute to, you're welcome to join us.

Andrei Alexandrescu napisał:

> On 08/04/2010 01:38 PM, Tomek Sowiński wrote:
>> Andrei Alexandrescu napisał:
>>
>>> I tested on two laptops (Ubuntu and Mac OSX). I compiled the two languages' standard libraries by using the provided makefiles, after touching all .go and all .d files involved. Then I divided the compilation times by the line counts of *.go/*.d files as wc has them and compared the results.
>>>
>>> On OSX dmd was 4.3 times faster. On Ubuntu, the ratio was 4.45.
>>
>> Was D with or without --unittest? I'm asking because unittests are instances and plenty of Phobos is templates for which AFAIK much work is deferred to instantiation.
> 
> No -unittest. In Phobos the unittest build turns -unittest on separately for each module, so I can't quickly test the build speed with -unittest on. That being said, there's still plenty of non-template code in Phobos.
> 
> BTW Phobos is built in release mode (as I assume go's library is). Building in debug mode reduces build time by more than a third.

Hm.. OK. I'm looking forward to round 2, measures taken at the end of the food chain -- a large executable program. Hopefully both languages will soon have enough speciments to choose from.


Tomek

Thu, 05 Aug 2010 11:41:58 -0700, Walter Bright wrote:

> retard wrote:
>> Ok, Walter is working on a 64-bit compiler, then on the shared library support. That's great. But many of us would like to know who is
>> 
>>  * managing the communication with the user community * managing the
>>  communication with the language/compiler developers * managing the
>>  bugfixes to the spec
>>  * managing the compiler bugfix release (minor version) process *
>>  managing the language development debate * coordinating the future
>>  language development (roadmap page of the trac) * managing the public
>>  relations with the people outside the core
>> community
>> 
>> It seems Walter wants to be a lonely wolf. Nobody else is allowed to do anything listed above unless you're Andrei. There are no managers, we only have experts working with their favorite features and no communication exists between these persons or the community.
> 
> There are quite a few people actively contributing to all of the above. Perhaps you don't monitor the D mailing lists where a lot of this activity is going on.
> 
> If there's a particular one you want to contribute to, you're welcome to join us.

I'd like to design D 3.0 features and the new LLVM based compiler with bearophile and fill the roadmap page in the trac page. Is that ok? How can I start?

On 08/05/2010 05:34 PM, dsimcha wrote:
> == Quote from BCS (none@anon.com)'s article
>> A possibly better solution would be to use an error handling strategy approach,
>> Have the called function throw and exception supplied by the calling function.
>>>
>
> I wouldn't use this, at least without a sane default exception, because it forces
> the caller of a function to write boilerplate for error handling (beyond what's
> necessary for cleanup/rollback in case of an error) even if the caller can't
> actually handle the errors.  This severely smacks of overengineering and making
> the uncommon case possible at the expense of making the common case simple, and
> largely defeats two main purposes for exceptions:
>
> 1.  Noone should have to explicitly think about how to propagate any error.  One
> and only one level should have to think about handling it and the rest of the
> levels just need to be able to clean up in case of an error.
>
> 2.  Exceptions are supposed to provide a sane default that's useful for small
> scripts (exiting the program with a decent error message).  If you force the user
> to explicitly specify an exception to be thrown, you lose this convenience.
>
> On the other hand, if you provide a sane default exception, this might be
> reasonable as long as it doesn't bloat the API too much.

enforce(a<b, "a needs to be smaller than b"); // Exception
enforceEx!(RangeError)(a < length, "a out of bounds"); //RangeError

Isn't this exactly what you want?

Probably, an overload for enforce could be made, so this works:

enforce(a < len, new RangeError("out of bounds"));

retard wrote:
> I understood that all the contributors are waiting for the decision of a single person.

Not true, that only applies to the compiler. Phobos is managed by several people who have commit privileges.

> Walter needs to review all compiler patches,

Yes, because I need to keep a handle on exactly how the compiler works. If I lose track of it, it can become a mess of things like "this seems to work" with little understanding. I want to especially thank Don Clugston for his invaluable help in reviewing submitted compiler patches, testing them, fixing a lot of the hard problems, and making it easy for me.


> he needs to review all patches to the spec, he needs to defend D on reddit, newsgroups, and all other forums.

More like I want to. Anyone else is welcome to help out here. I am hardly in a position to stop anyone from helping there <g>.

> He handles the whole release process.

That actually is about to change.

> He doesn't tell anything about future directions so nobody knows about them.

What's unclear about it?

> The management model doesn't scale when you get more and more contributors. At some point Walter won't have enough time to review all contributions even if it didn't do anything else.

You're right, I can't review them all. In particular, I am fairly uninvolved in the development of Phobos, other than popping up now and then to complain about something :-)

> For example now that he is focusing on 64-bit support, all discussion about rewriting the spec, fixing bugs, improving the other parts of the toolchain, or developing the language further (D 2.1 or 3.0) has stalled. 

This is nonsense, as I'm not stopping anyone from helping out with any of that. In fact, tomorrow I have a lunch date with a fellow who is working on a D debugger.

As another example of many who have stepped up with invaluable help, Shin Fujishiro did the pioneering work to get D2 working on FreeBSD.

> Many people have asked bearophile to stop discussing new language features because it takes away too much valuable time from Walter. Something is wrong here.

I haven't asked bearophile or anyone else to stop discussing new language features. Anyone is free on this n.g. to ask whatever they want of others, and everyone is free to accede to or ignore those requests.

Here's an incomplete list of people who are in charge of various aspects of D:

Me: compiler
Sean: druntime
Brad Roberts: bugzilla, mailing lists, D test suite
Brad Anderson: D source code repository
Jan Knepper: site hosting
Several people: Phobos (generally under Andrei's leadership)
Helmut Leitner: D wiki
Andrei: build master (coming soon!)

Of course, LDC, GDC, Tango, Dil, and all the other libraries and tools, etc., are all led by their various self-selected groups, not me.

retard wrote:
> I'd like to design D 3.0 features and the new LLVM based compiler with bearophile and fill the roadmap page in the trac page. Is that ok? How can I start?

Just do it. You don't need anyone's permission.