November 19, 2021
On Friday, 19 November 2021 at 03:00:14 UTC, Adam D Ruppe wrote:
> ..
>
> But what I'd push for is the steering group reform specifically as a condition to stop the fork. The other details can be worked out once we have that formed. The steering group must have binding authority - if they decide a change is going to happen, it gets merged in and no individual can overrule that.

A steering group needs members who are permanent, and members who are rotated (on a fixed term). Otherwise it will lead to rot.

Getting a permanent seat on the steering group needs to be something that is hard fought.

There is only one person I know of, that deserves that position, at the moment (possibly two, but I'll stick with one for now).
November 19, 2021

On Friday, 19 November 2021 at 03:00:14 UTC, Adam D Ruppe wrote:

>

aforementioned change. Personally what I want is a new leadership structure, a steering group of probably seven, maybe eleven, selected by D stakeholders on some term basis, probably annually, who have authority to make whatever changes they see fit. From there, they guide the language.

You need representation (diversity) otherwise you will end up with many of the same issues.

You also need a shared vision. Simpler or more features?

You also need to restructure compiler internals to get more people interested. So a merge is not realistic.

>

The process I propose is letting the steering committee deliberate on them in a private forum thread, which is then made public (but read only) after the decision is locked. This decision can thus be reviewed without being bikeshedded to hell.

Look up Group Think. The road to hell is paved with good intensions.

November 19, 2021

On Friday, 19 November 2021 at 08:07:11 UTC, Ola Fosheim Grøstad wrote:

>

Look up Group Think. The road to hell is paved with good intensions.

(To be fair, look up design by committee and analysis paralysis as well.)

November 19, 2021

On Friday, 19 November 2021 at 08:08:38 UTC, FeepingCreature wrote:

>

On Friday, 19 November 2021 at 08:07:11 UTC, Ola Fosheim Grøstad wrote:

>

Look up Group Think. The road to hell is paved with good intensions.

(To be fair, look up design by committee and analysis paralysis as well.)

"Analysis paralysis" in PL design is a sign that the chosen approach does not lead to the goal, like having an unsound typesystem. Start over from scratch is often the better solution.

November 19, 2021
On Friday, 19 November 2021 at 01:14:47 UTC, Walter Bright wrote:
> On 11/16/2021 12:55 AM, Abdulhaq wrote:
>> Is there a set of features that, when fully working, will mean that D2 is now finished? Or will it forever be in a state of ongoing feature development?
>> 
>> We all know that properly finishing and polishing the last 10% of a software project takes 90% of the time. Is there a timescale for that? What platforms will it support?
>
> No software development is ever done as long as people are still using it.

That's true, of course. What I mean is, nail all those boring I-know-I-should-fix-those-small-to-medium-size-problems-but-I'm-not-sure-how and park, for now, the interesting DIPs etc. Finalise the feature set for an LTS version and really polish it to make it the best experience it can be for a developer, within the bounds of what is actually possible of course. Make it the focus of the community. Commit to supporting that release for bugs and security issues, on a nominated set of platforms, for a nominated period of time.

This is my proposal if you want to grow the number of corporate developers using D. Maybe you don't, that's your call obviously.

If I'm barking up the wrong tree then set me straight and make it clear what the vision actually is. Personally I'm also curious, do you have a particular set of developers in mind as users, or are you just scratching your own itch and hoping that it will also be good for others? Both answers are perfectly reasonable, but it would be nice to know the answer.
November 19, 2021

On Friday, 19 November 2021 at 08:41:05 UTC, Abdulhaq wrote:

>

That's true, of course. What I mean is, nail all those boring I-know-I-should-fix-those-small-to-medium-size-problems-but-I'm-not-sure-how and park, for now, the interesting DIPs etc. Finalise the feature set for an LTS version and really polish it to make it the best experience it can be for a developer, within the bounds of what is actually possible of course. Make it the focus of the community. Commit to supporting that release for bugs and security issues, on a nominated set of platforms, for a nominated period of time.

I recommend you watch Atila's upcoming DConf Online talk:

https://youtu.be/UqW42_8kn0s

That will cover part of what you're asking about. And I expect that the revised governance proposal Mathias Lang is preparing to put forward in the coming weeks will create the framework where we'll be able to marshal and direct community resources (volunteered and paid) toward specific tasks to enhance the ecosystem. That includes the finalization/polishing of troubled language features and any potential changes to the release process.

See the following meeting summary for background:

https://forum.dlang.org/thread/fnzuguuewsvzswpwiwar@forum.dlang.org

November 19, 2021

On Thursday, 18 November 2021 at 18:05:38 UTC, Abdulhaq wrote:

>

I just want to give a POV that I think can help lift the number of users.

Doing things with D help lift the number of users.

Constant, harsh, unsubstantiated criticism on the main communication channel (these very forums) for D doesn't help getting more users. No language has an anti-themselves campaign going on for years on their main communication channels.

Imagine you child is bullied at school. Would your idea of helping him is to make public criticism of the many ways he would have to change in order to have friends?
No, this is just bullying, by people who enjoy doing just that.

November 19, 2021

On Friday, 19 November 2021 at 11:24:15 UTC, Guillaume Piolat wrote:

>

Imagine you child is bullied at school. Would your idea of helping him is to make public criticism of the many ways he would have to change in order to have friends?
No, this is just bullying, by people who enjoy doing just that.

We should collect criticism,
If you want to criticize, please see whether the opinion has been put forward.

November 19, 2021

On Friday, 19 November 2021 at 11:36:48 UTC, zjh wrote:

>

We should collect criticism,

Posts should also be classified.
Such as opinion/question/..., etc.
Our problem is organization.
Excellent posts should also be scored,And reward.
etc...

November 19, 2021

On Friday, 19 November 2021 at 11:24:15 UTC, Guillaume Piolat wrote:

>

On Thursday, 18 November 2021 at 18:05:38 UTC, Abdulhaq wrote:

>

I just want to give a POV that I think can help lift the number of users.

Doing things with D help lift the number of users.

D has enough users, but I project most of them are like Abdulhaq and myself. They write D code occasionally in their hobbyspace and would like to see a situation where you would choose D because it is objectively the best choice. Right now D is not the most rational choice, unless you do exactly what you do: write your own foundation and extend the compiler with what you need (like SIMD support). That is a lot to demand of others… So you are very demanding in your attitude!

I've come to the conclusion that for me D will never move out of hobbyspace (well, maybe if I write an audioplugin). That conclusion made me happier about D!

Abdulhaq still dreams of using D outside his hobbyspace, but he clearly cannot make a salespitch at his workplace by appealing to emotions, he has to make a rational argument for it.

>

No, this is just bullying, by people who enjoy doing just that.

You've bullied me repeatedly. I never bullied you. :-P Bullying a technical construct and a development process is not a concept… Hurting the compiler's self confidence or something?

For instance, let us return to the introduction of @nogc. If you read the DIP thread on that you'll see that Manu, Mike and other low level coders were not enthusiastic. Manu wanted ARC at the time. You know, a solid compiler backed memory management solution. The survey from 2010 shows that nobody wanted -nogc as an option. The conclusion is that everybody that use D wants managed memory backed by the compiler (some kind of automatic memory management). @nogc does not satisfy that need, it is more like an escape-hatch.

At the end of the day it comes down to wanting to write code that is and looks beautiful.

You want this yourself. You want to get rid of the "@" in front of attributes.

Aesthetics matter.

Aesthetics in memory management.
Aesthetics in semantics.
Aesthetics in syntax.

So when you go to bed you can go to sleep knowing that you created something beautiful that day.

People want this from D. I think you do too.