On Friday, 19 December 2014 at 11:39:08 UTC, Joakim wrote:
> On Friday, 19 December 2014 at 10:04:34 UTC, Walter Bright wrote:
>> On 12/18/2014 1:39 PM, Vic wrote:
>>> But this is not the culture of the creators. They think adding features is fun.
>>
>> I spent most of my time saying "no" to new features and trying to find ways to support things without adding features.
>
> I think his point is that you haven't said "no" enough. ;) A tough job, but then BDFL doesn't come without its pains.

I don't think the problem is saying no here.

The problem is that many feature are incomplete or have holes or are not orthogonal to each others. Let me take 2 simple examples :
 - type qualifiers are transitive. Except for delegate's context.
 - There is no implicit sharing. Except via delegate (because of the above mentioned point), exceptions and promotion of pure function's result.

The problem with having these holes, is that you can't rely on anything. That makes it very hard to write reliable library, or to add new features as you get a myriad of special cases all over the place.

Sometime, fixing these holes require adding new feature, or extending a bit existing ones. That is fine as this new thing will allow for closure of what is already open. This is a beneficial addition and saying no would be a step back.

In other situations, adding new feature simply extends the language and create new specials cases. In which case, no or later is the appropriate answer at this point.

On Friday, 19 December 2014 at 13:15:21 UTC, Mike Parker wrote:
> Which obviously comes from a lack of any historical reference. If Vic had been around this community longer than he actually has, he never would have made such a remark. Walter's nickname should be Dr. No.

Well, the point is not that one should say "no", but assign priorities (and degree of certainty) to features/enhancements/fixes and attach them to milestones that gives a predictable path to a series of stable release.

So, "no" is not a good answer, but "not for release X, if this goes in it should be designed along with feature Y which is planned for release Z" is an answer that might encourage people to create a proof-of-concept-prototype without expecting it to go in right away.

On Friday, 19 December 2014 at 14:03:06 UTC, deadalnix wrote:
> On Friday, 19 December 2014 at 11:39:08 UTC, Joakim wrote:
>> On Friday, 19 December 2014 at 10:04:34 UTC, Walter Bright wrote:
>>> On 12/18/2014 1:39 PM, Vic wrote:
>>>> But this is not the culture of the creators. They think adding features is fun.
>>>
>>> I spent most of my time saying "no" to new features and trying to find ways to support things without adding features.
>>
>> I think his point is that you haven't said "no" enough. ;) A tough job, but then BDFL doesn't come without its pains.
>
> I don't think the problem is saying no here.
>
> The problem is that many feature are incomplete or have holes or are not orthogonal to each others. Let me take 2 simple examples :
>  - type qualifiers are transitive. Except for delegate's context.
>  - There is no implicit sharing. Except via delegate (because of the above mentioned point), exceptions and promotion of pure function's result.
>
> The problem with having these holes, is that you can't rely on anything. That makes it very hard to write reliable library, or to add new features as you get a myriad of special cases all over the place.
>
> Sometime, fixing these holes require adding new feature, or extending a bit existing ones. That is fine as this new thing will allow for closure of what is already open. This is a beneficial addition and saying no would be a step back.
>
> In other situations, adding new feature simply extends the language and create new specials cases. In which case, no or later is the appropriate answer at this point.

While implementation quality of all these features is no doubt a big part of the problem, my guess, based on Vic's previous post about stripping down the language to a stable core, is that he'd prefer if some subset of D's features were put off or ditched altogether.  Of course, that ties into the fact that the more features you have, the less time you have to polish them and make sure each feature interacts well with everything else, particularly given D's small core team.

As for Walter already saying "no" a lot, given how many features D has, obviously one can still wish he went from 99% "no" to 99.5%. ;)  You don't need to be around the D community forever to feel that D still has too many features that made it in.

> As for Walter already saying "no" a lot, given how many features D has, obviously one can still wish he went from 99% "no" to 99.5%. ;)  You don't need to be around the D community forever to feel that D still has too many features that made it in.

Care to name a few and justify why exactly those features should be gone?

On Friday, 19 December 2014 at 14:38:02 UTC, Tobias Pankrath wrote:
>> As for Walter already saying "no" a lot, given how many features D has, obviously one can still wish he went from 99% "no" to 99.5%. ;)  You don't need to be around the D community forever to feel that D still has too many features that made it in.
>
> Care to name a few and justify why exactly those features should be gone?

No, as that's not really my problem.  I was simply trying to clarify the argument others have made, that the language seems overstuffed and overwhelming, which I have experienced at times but I'm not personally complaining about.

To Walter, the language may feel like it consists of a small, well-chosen set of features, given the many others he's nixed over the years.  But to others coming to D from even smaller or less well-thought out languages, even that set may seem too big and overwhelming to navigate.  Certainly, they may feel that it would be better to focus on honing less features, rather than adding more half-baked but potentially good ones, however nice they'd be to have.

On Friday, 19 December 2014 at 14:38:02 UTC, Tobias Pankrath wrote:
>> As for Walter already saying "no" a lot, given how many features D has, obviously one can still wish he went from 99% "no" to 99.5%. ;)  You don't need to be around the D community forever to feel that D still has too many features that made it in.
>
> Care to name a few and justify why exactly those features should be gone?

 - lazy . It is completely unable to interact with all qualifier code that run should be able to have.
 - scope in its current state. Do not ensure anything.
 - in and out parameters.
 - optional parenthesis. They cause confusion and great language complication in their current form.
 - Non first class functions. Useless baggage from C and C++, which only benefit are to complicate the situation with optional () and cause a large part of the standard lib to go banana when passed a non first class function via alias parameter.
 - inout. Completely underpowered for its cost, ambiguous and can cause compiler crash in some ambiguous cases.
 - most of traits. They are completely inconsistent, for instance, some return aliases, some return strings and there is no way to really know.
 - __parameters. Yes, this is a keyword.

That is what you get you add half assed feature to solve an immediate problem, but don't look at the broader picture.

On Friday, 19 December 2014 at 14:58:07 UTC, Joakim wrote:
> On Friday, 19 December 2014 at 14:38:02 UTC, Tobias Pankrath wrote:
>>> As for Walter already saying "no" a lot, given how many features D has, obviously one can still wish he went from 99% "no" to 99.5%. ;)  You don't need to be around the D community forever to feel that D still has too many features that made it in.
>>
>> Care to name a few and justify why exactly those features should be gone?
>
> No, as that's not really my problem.  I was simply trying to clarify the argument others have made, that the language seems overstuffed and overwhelming, which I have experienced at times but I'm not personally complaining about.>

It is a worthless claim to make that there is too much of something, if you cannot come up with an concrete example. "I've got that gut feeling, that" is not even remotely an argument and just kills time of everyone in this discussion.

If we want to discuss the future of the language, it's totally pointless to do it in an abstract way. “We need to make the language more stable“ is not a goal or something, it is totally unclear what that actually means, why this is important in the first place, how we can say that we have accomplished it or what we need to do to realise that goal.

On Friday, 19 December 2014 at 15:11:30 UTC, Tobias Pankrath wrote:
> On Friday, 19 December 2014 at 14:58:07 UTC, Joakim wrote:
>> On Friday, 19 December 2014 at 14:38:02 UTC, Tobias Pankrath wrote:
>>>> As for Walter already saying "no" a lot, given how many features D has, obviously one can still wish he went from 99% "no" to 99.5%. ;)  You don't need to be around the D community forever to feel that D still has too many features that made it in.
>>>
>>> Care to name a few and justify why exactly those features should be gone?
>>
>> No, as that's not really my problem.  I was simply trying to clarify the argument others have made, that the language seems overstuffed and overwhelming, which I have experienced at times but I'm not personally complaining about.>
>
> It is a worthless claim to make that there is too much of something, if you cannot come up with an concrete example. "I've got that gut feeling, that" is not even remotely an argument and just kills time of everyone in this discussion.
>
> If we want to discuss the future of the language, it's totally pointless to do it in an abstract way. “We need to make the language more stable“ is not a goal or something, it is totally unclear what that actually means, why this is important in the first place, how we can say that we have accomplished it or what we need to do to realise that goal.

I have no dog in this fight.  I was merely pointing out to Walter and Mike that it's possible to say "no" a lot and still have others wish you had said "no" even more. :) There's no particular feature that I wish wasn't there, though of course there are many features that many wish were implemented or worked together better, as deadalnix points out.

When Vic suggested a split into a stable core and an experimental layer, I suggested documenting the perceived stability of various features instead, so that users could have a guide for what features might be more problematic without having to do a deep-dive in bugzilla to figure it out for themselves.  I didn't back a split or have not suggested removing features.

On Friday, 19 December 2014 at 15:11:30 UTC, Tobias Pankrath wrote:
> If we want to discuss the future of the language, it's totally pointless to do it in an abstract way. “We need to make the language more stable“ is not a goal or something, it is totally unclear what that actually means, why this is important in the first place, how we can say that we have accomplished it or what we need to do to realise that goal.

Yes, but it would be easy to define some focused goals for each release and refuse to touch stuff that belongs to a later release. E.g.

2.70-2.79:
- fix all problems related to private changes in libraries breaking application-code

2.80-2.89:
- focus on polishing support for applications that use GC and can take the collection hit

2.90-2.99:
- focus on polishing support for applications that are real time and don't use GC
- standard lib fully @nogc
- scope etc

3.0:
- breaking change: full clean up of syntax
- non-GC ownership model
- optional precise GC
- remove less important features: lazy, etc…

3.1:
- 3.0 update, supplements features in 3.0

3.2-3.3:
- faster compilation

3.4-3.5
- profiling guided optimization
- whole program optimization

On Friday, 19 December 2014 at 16:45:40 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 19 December 2014 at 15:11:30 UTC, Tobias Pankrath wrote:
>> If we want to discuss the future of the language, it's totally pointless to do it in an abstract way. “We need to make the language more stable“ is not a goal or something, it is totally unclear what that actually means, why this is important in the first place, how we can say that we have accomplished it or what we need to do to realise that goal.
>
> Yes, but it would be easy to define some focused goals for each release and refuse to touch stuff that belongs to a later release. E.g.
>
> 2.70-2.79:
> - fix all problems related to private changes in libraries breaking application-code
>
> 2.80-2.89:
> - focus on polishing support for applications that use GC and can take the collection hit
>
> 2.90-2.99:
> - focus on polishing support for applications that are real time and don't use GC
> - standard lib fully @nogc
> - scope etc
>
> 3.0:
> - breaking change: full clean up of syntax
> - non-GC ownership model
> - optional precise GC
> - remove less important features: lazy, etc…
>
> 3.1:
> - 3.0 update, supplements features in 3.0
>
> 3.2-3.3:
> - faster compilation
>
> 3.4-3.5
> - profiling guided optimization
> - whole program optimization

How would that improve the development process? Which problems that we currently face does that solve and why? I'm not trying to troll here.