On Wed, 18 Jan 2012 13:57:58 -0800, Walter Bright <newshound2@digitalmars.com> wrote:

> On 1/18/2012 1:27 PM, Patrick Stewart wrote:
>> How about putting equal effort in keeping existing D users? There is more
>> than one blogs online of ex D users with some pretty solid arguments why they
>> abandoned D. And those args are usually not some missing shiny feature X but
>> feature Y D already has but it is broken.
>
> I do attach far more importance to that than to reasons people who never used D do not use D.
>
>
>> Just saying focusing on bright future is not excuse to forget about imperfect
>> now.
>
> I'm not saying it is.
>
> The point is, we have limited resources. We have to put those resources where they will have the most effect.

I would argue that what would have the most effect is a concerted effort to stabilize the compiler. That means normalizing the differences between DMD/DRT, the Spec, and TDPL. That means taking a break from anything new (regardless of how badly we want them ... *COFF*COFF*), doing a thorough audit of the open issues and prioritizing compiler issues first. Then dedicated a release or three to doing nothing but fixing those issues. There are 2719 open issues in the bugtracker; that number alone will scare off many potential users. And the number of ICE's is much higher than it really should be to call DMD stable. In open-source terms, DMD is beta. I'm leaving out Phobos here specifically because it doesn't interact with the compiler nearly as much as the runtime does.

I would also argue that the above point is even more important in light of the fact that DMD has such limited resources. Accurate and efficient targeting of those resources is crucial to D's survival. New features, while exciting, only introduce the opportunity for new bugs and regressions. But without a stable compiler a language is just a theory and some mathematical proofs.

Once we have a stable compiler it gets much easier to build out libraries of code. These libraries are what really sell the language as they not only provide a preexisting toolbox for new developers, but also show that the language is mature enough to reliably handle complex bodies of code. Also once a stable compiler exists writing coherent documentation also gets much easier as the number of undefined and undocumented behaviors is significantly reduced. Ideally the documentation would have been written first but at this point I think it is way to much work for said limited resources to document and code at the same time.

To be honest, I think this is the end-goal that Andrei is shooting for in his "Planning Software?" thread...

-- 
Adam Wilson
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

On Wednesday, 18 January 2012 at 22:15:25 UTC, Adam Wilson wrote:
> On Wed, 18 Jan 2012 13:57:58 -0800, Walter Bright <newshound2@digitalmars.com> wrote:
>
>> On 1/18/2012 1:27 PM, Patrick Stewart wrote:
>>> How about putting equal effort in keeping existing D users? There is more
>>> than one blogs online of ex D users with some pretty solid arguments why they
>>> abandoned D. And those args are usually not some missing shiny feature X but
>>> feature Y D already has but it is broken.
>>
>> I do attach far more importance to that than to reasons people who never used D do not use D.
>>
>>
>>> Just saying focusing on bright future is not excuse to forget about imperfect
>>> now.
>>
>> I'm not saying it is.
>>
>> The point is, we have limited resources. We have to put those resources where they will have the most effect.
>
> I would argue that what would have the most effect is a concerted effort to stabilize the compiler. That means normalizing the differences between DMD/DRT, the Spec, and TDPL. That means taking a break from anything new (regardless of how badly we want them ... *COFF*COFF*), doing a thorough audit of the open issues and prioritizing compiler issues first. Then dedicated a release or three to doing nothing but fixing those issues. There are 2719 open issues in the bugtracker; that number alone will scare off many potential users. And the number of ICE's is much higher than it really should be to call DMD stable. In open-source terms, DMD is beta. I'm leaving out Phobos here specifically because it doesn't interact with the compiler nearly as much as the runtime does.
>
> I would also argue that the above point is even more important in light of the fact that DMD has such limited resources. Accurate and efficient targeting of those resources is crucial to D's survival. New features, while exciting, only introduce the opportunity for new bugs and regressions. But without a stable compiler a language is just a theory and some mathematical proofs.
>
> Once we have a stable compiler it gets much easier to build out libraries of code. These libraries are what really sell the language as they not only provide a preexisting toolbox for new developers, but also show that the language is mature enough to reliably handle complex bodies of code. Also once a stable compiler exists writing coherent documentation also gets much easier as the number of undefined and undocumented behaviors is significantly reduced. Ideally the documentation would have been written first but at this point I think it is way to much work for said limited resources to document and code at the same time.
>
> To be honest, I think this is the end-goal that Andrei is shooting for in his "Planning Software?" thread...

Can't bypass without saying "+1".

I have been following D development for almost 2 years and most of the time this is what I was really _dreaming_ about. What prevents me most from using D other than for small experiments is not really lack of/unfinished features, but very unclear development processes. I have been reading newsgroup silently and attentively for about half a year before got any slightest understanding of what is really happening.

Just personal feeling, of course.

On 1/18/2012 2:15 PM, Adam Wilson wrote:
> I would argue that what would have the most effect is a concerted effort to
> stabilize the compiler. That means normalizing the differences between DMD/DRT,
> the Spec, and TDPL. That means taking a break from anything new (regardless of
> how badly we want them ... *COFF*COFF*), doing a thorough audit of the open
> issues and prioritizing compiler issues first. Then dedicated a release or three
> to doing nothing but fixing those issues. There are 2719 open issues in the
> bugtracker; that number alone will scare off many potential users. And the
> number of ICE's is much higher than it really should be to call DMD stable. In
> open-source terms, DMD is beta. I'm leaving out Phobos here specifically because
> it doesn't interact with the compiler nearly as much as the runtime does.

Take a look at the changelog. I just don't see how anyone could conclude that is not exactly what we are doing. Here's the current list for the upcoming version of D2:


314 - [module] Static, renamed, and selective imports are always public
796 - Asserting a null object reference throws AssertError Failure internal\invariant.d(14) or Access Violation
1313 - out/body disables escape analysis
2411 - Reference Tuple Foreach
2442 - opApply does not allow inferring parameter types when overloaded on const
2443 - opApply should allow delegates that are not ref if it makes no sense
2997 - allMembers does not return interface members
3092 - Indexing a tuple produces a tuple containing the indexed element
3187 - Nested foreach over opApply doesn't work
3235 - [tdpl] Function literals must be deduced as "function" or "delegate"
4251 - Hole in the const system: immutable(T)[] implicitly casts to ref const(T)[]
4413 - typeof(this) doesn't work in method template signature
4523 - [tdpl] .remove method for Associative Arrays returns void in all cases
4550 - D2 Language Docs: http://www.digitalmars.com/d/2.0/statement.html
4553 - D2 Language Docs: http://www.digitalmars.com/d/2.0/struct.html
4647 - [tdpl] Cannot explicitly call final interface method, ambiguous calls allowed
4675 - [tdpl] Eponymous Template should hide internal names
4711 - Incorrect handling of && operator with void operand
4940 - ICE(symbol.c): Accessing tuple-typed field of struct literal with user-defined constructor
5493 - Able to overwrite immutable data by passing through ref function parameter
5605 - [tdpl] foreach with ranges doesn't support opSlice()
6037 - [CTFE] recursive ref parameters evaluated incorrectly
6205 - Strongly-pure nothrow functions with ignored return value are entirely stripped even if it contains a failing 'assert'.
6208 - Parameter storage classes are ignored in template function deducing.
6364 - Static struct's destructor called on exit of function
6473 - Stack overflow with struct destructor as default parameter
6701 - template specialization resolution failure
6714 - [tdpl] Type inference for parameters of function and delegate literals
6933 - Segfault(declaration.c) using struct with destructor in CTFE
6934 - [CTFE] can't use $ in a slice of an array passed by ref
6939 - wrong type qualifier combination
6940 - immutable(int*)*/immutable(int)** and int** do not combine
6964 - Error message with __error: static assert(undefined+1)
6984 - CTFE generates a torrent of spurious errors, if there was a previous error
6985 - [CTFE] Non-constant case expressions can't be interpreted
6995 - [CTFE] can't interpret static template method
7011 - No line number error for vector power
7037 - TemplateTypeParameterSpecialization works differently from IsExpression regarding alias this
7043 - CTFE: ICE illegal reference value 0LU, only with -inline
7073 - Parsing of class-returning varargs function inside module ctor fails
7108 - ICE: TraitsExp::semantic(Scope*) 2.056 -> 2.057 regression - segfault
7120 - Scope Delegates + Delegate Literals
7123 - static assert(is(typeof(toDelegate(&main)))) is false
7124 - Alias this type is not considered in template type deduction
7127 - Const-related infinite recursion in DWARF generation
7133 - [tdpl] There should be no empty statement
7136 - alias this lookup should run before merging modifiers of both sides.
7143 - [CTFE] cannot compare class references with "is"
7144 - [CTFE] base class does not call overridden members
7154 - [CTFE] failing downcast causes error
7158 - [CTFE] ICE(interpret.c) calling a class member using a dotvar expression
7160 - Regression(2.057): ICE(dsymbol.c:1052) ICE using __traits(derivedMembers)
7162 - [CTFE] "bool || void" expression crashes dmd
7165 - [CTFE] ice converting null pointer to bool with constant member function
7168 - Regression(2.057) __traits(allMembers) returns wrong tuple
7170 - [UFCS] array + specialized template member syntax causes ICE
7173 - dmd: glue.c:1065: virtual unsigned int Type::totym(): Assertion `0' failed.
7185 - [CTFE] ICE on changing char array length
7187 - Regression(head 12d62ca5): [CTFE] ICE on slicing
7189 - inline failed
7190 - Tuple length incorrect
7193 - Regression(2.058head): ICE: delete lambda expression crashes dmd
7194 - [CTFE] Incorrect behaviour with pointers as local struct variable
7196 - Unfair function address overload resolution
7201 - Lambda template assignment to variable
7207 - Explicit cast should resolve lambda type
7212 - Regression(Head): ICE with overload resolution and delegate/function inference
7217 - [CTFE] ICE on accessing struct array field
7218 - Nested function with contract is rejected
7232 - Warning: statement is not reachable has no line number
7239 - C style struct initialization doesn't work with aliases
7245 - [CTFE] Address of ref foreach parameter changes to point after array
7248 - [CTFE] Stack overflow on using struct filed pointer with address of array element
7266 - [CTFE] Assign to ref param (that's taken from struct member) is noop
7278 - Templated struct (instantiated with null) can't access its own members
7285 - Implicit fixed-size array cast
7290 - Heap allocation with scoped delegate literal
7309 - [2.058] Regression caused by new inlining code

Walter:

> Here's the current list for the upcoming version of D2:

It's an impressive list, as usual :-)

But as I have recently explained (on the base on an old comment of yours) not all bugs are equal. Most bugs in that list are kind of irrelevant to me, they don't hit my code significantly, or often enough. Only few of those bugs are able to change the way I write D2 code, because their presence forces me to use work-arounds, or they forbid me to use certain idioms or certain kinds of code.

This is why I think a little group of those bugs is more important than fixing a hundred of other bugs (on the other hand I understand that other people write code different from mine, so they may find different bugs as more important. But the purpose of Bugzilla voting is right to average such differences in programmers needs).

Fixing this bug improves my experience of using modules:
> 314 - [module] Static, renamed, and selective imports are always public

Fixing this bug allows me to avoid to write many "helper" templates:
> 4675 - [tdpl] Eponymous Template should hide internal names

The recent improvements in byKey and byValue allow me to use associative arrays better and more efficiently.

The improvements of the way const/immutable arrays are giving to functions allow me to use std.algorithm on const arrays, this avoids me to put cast() in many situations, it suddenly makes std.algorithm a notch more useful.

Bye,
bearophile

Walter Bright Wrote:

> On 1/18/2012 1:27 PM, Patrick Stewart wrote:
> > How about putting equal effort in keeping existing D users? There is more than one blogs online of ex D users with some pretty solid arguments why they abandoned D. And those args are usually not some missing shiny feature X but feature Y D already has but it is broken.
> 
> I do attach far more importance to that than to reasons people who never used D do not use D.
> 
> 
> > Just saying focusing on bright future is not excuse to forget about imperfect now.
> 
> I'm not saying it is.
> 
> The point is, we have limited resources. We have to put those resources where they will have the most effect.
> 

Would you argue that standardizing and finishing language core is first step and library is next?

Also, I would argue that resources are not limited as in modest, but wasted.

I am sorry to see many D community projects and libraries dead as they are targeted for D1 and not portable to D2, or just locked to specific version of D and not transferable to latest version due some bug.

I think it is possible for community to make all necessary libraries and tools once the D is "carved in stone". I suppose D1 is attempt to do that, but not having ready substitute yet (D2 not working as advertised) and D1's clock ticking away, it is risky gamble to say at least.

To put it plain and simple, I have strong feeling D development is motivated by desire to add latest ideas and features and not by desire to produce practical and stable tool.

On 1/18/12 5:13 PM, Walter Bright wrote:
> Take a look at the changelog. I just don't see how anyone could conclude
> that is not exactly what we are doing. Here's the current list for the
> upcoming version of D2:
[snip]

Great work everybody. Some issues are lateral to the size and might of the list:

1. There was no plan in place for fixing these bugs vs. others; the process was rather chaotic, and at least one bug was fixed because one user took the time to email me a little novel complaining about it.

2. There is no projected date of release.

3. There is no plan going forward, e.g. what bugs will be fixed later.

4. A lot of the important tdpl bugs should have been filed, triaged, and fixed a long time ago.

5. There's no sense of the "length of the pipeline", i.e. how long it takes until a given bug is triaged.

Until recently there were enough big issues that it didn't really matter which were solved - all fruit was low hanging! But at this point we must get better organized.


Andrei

On 1/18/2012 3:52 PM, bearophile wrote:
> Most bugs in that list are kind of irrelevant to me, they
> don't hit my code significantly, or often enough.

All of them hit somebody.

On 1/18/2012 4:03 PM, Patrick Stewart wrote:
> I am sorry to see many D community projects and libraries dead as they are
> targeted for D1 and not portable to D2, or just locked to specific version of
> D and not transferable to latest version due some bug.

I am sorry about Tango apps being incompatible. I cannot do anything about that.


> I think it is possible for community to make all necessary libraries and
> tools once the D is "carved in stone". I suppose D1 is attempt to do that,
> but not having ready substitute yet (D2 not working as advertised) and D1's
> clock ticking away, it is risky gamble to say at least.

What issue with D2 is blocking you?


> To put it plain and simple, I have strong feeling D development is motivated
> by desire to add latest ideas and features and not by desire to produce
> practical and stable tool.

People often write postings, where in the very same posting, they'll write that they absolutely must have new feature X now, and that no new features should be added.

How would you resolve this?

On Wed, 18 Jan 2012 16:29:23 -0800, Walter Bright <newshound2@digitalmars.com> wrote:

> On 1/18/2012 4:03 PM, Patrick Stewart wrote:
>> I am sorry to see many D community projects and libraries dead as they are
>> targeted for D1 and not portable to D2, or just locked to specific version of
>> D and not transferable to latest version due some bug.
>
> I am sorry about Tango apps being incompatible. I cannot do anything about that.
>
>
>> I think it is possible for community to make all necessary libraries and
>> tools once the D is "carved in stone". I suppose D1 is attempt to do that,
>> but not having ready substitute yet (D2 not working as advertised) and D1's
>> clock ticking away, it is risky gamble to say at least.
>
> What issue with D2 is blocking you?
>
>
>> To put it plain and simple, I have strong feeling D development is motivated
>> by desire to add latest ideas and features and not by desire to produce
>> practical and stable tool.
>
> People often write postings, where in the very same posting, they'll write that they absolutely must have new feature X now, and that no new features should be added.
>
> How would you resolve this?

Harsh as it sounds I'd ignore them, what they are really asking for is for you to stop working on everything else and work on their feature. Doing that is planning to fail.

-- 
Adam Wilson
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Andrei Alexandrescu:

> 5. There's no sense of the "length of the pipeline", i.e. how long it takes until a given bug is triaged.

Instead of fixing the N most old bugs every DMD release, I suggest to fix the N (N = 2 or 3 seems enough) most Bugzilla-voted bugs every DMD release :-)  (If this happens, then probably people will start voting more often and better).

Bye,
bearophile