On Thursday, 18 November 2021 at 18:20:18 UTC, H. S. Teoh wrote:
> On Thu, Nov 18, 2021 at 06:03:07PM +0000, Adam D Ruppe via Digitalmars-d wrote:
>> On Thursday, 18 November 2021 at 17:59:06 UTC, H. S. Teoh wrote:
>> > I'm seriously hoping Andrei pulls off stdv2, because that's the only way I see to move forward with Phobos.

Yes, that is my hope. An updated Phobos would change the culture of this project and make it exciting to contribute as part of the community, whether that's core development or libraries, blog posts, whatever.

>> It's that or we fork the language and seize control then just start actually fixing things.
>
> I have to say, the thought has crossed my mind a few times.  Only thing is, this community is already so tiny, splitting it would probably mean death to both resulting dialects.

The main reason to fork the language would be to make changes that should happen but aren't, or to do things that wouldn't be practical in the current language. That should bring in more users. On the other hand, if you don't have a *completed* language fork, the new won't be doing anything but taking manpower from the current. I honestly don't see anything other than the GC that would motivate a fork at this time.

On Thursday, 18 November 2021 at 20:18:43 UTC, bachmeier wrote:
> On Thursday, 18 November 2021 at 18:20:18 UTC, H. S. Teoh wrote:
>>> It's that or we fork the language and seize control then just start actually fixing things.
>>
>> I have to say, the thought has crossed my mind a few times.  Only thing is, this community is already so tiny, splitting it would probably mean death to both resulting dialects.
>
> The main reason to fork the language would be to make changes that should happen but aren't, or to do things that wouldn't be practical in the current language.

Think of a fork not as a competing company, but rather as a labor strike. The goal isn't actually to coexist with nor to vanquish D as we know it today, but rather to save it.

We'd get together and start a fork with the *goal* of getting the changes merged back upstream and fixing our broken governance model so it never has to happen this way again. Just like how labor unions go on strike to negotiate a better (binding) contract with the company - they aren't leaving their jobs, they are trying to work with the bosses to make their jobs better.

That's what D needs to get on track. Enough people to force some positive change to actually get going, then after that, we can negotiate on the specifics to merge back in.

On Thursday, 18 November 2021 at 13:29:59 UTC, Adam D Ruppe wrote:
>...
> The truth is really we're in the most stagnant part of D's history right now.
>....

This is why D needs a new motto. I mean, one that actually motivates.

'Fast code, fast'.... I wanna puke.

On Thu, Nov 18, 2021 at 10:20:49PM +0000, forkit via Digitalmars-d wrote:
> On Thursday, 18 November 2021 at 13:29:59 UTC, Adam D Ruppe wrote:
> > ...
> > The truth is really we're in the most stagnant part of D's history
> > right now.
> > ....
> 
> This is why D needs a new motto. I mean, one that actually motivates.
> 
> 'Fast code, fast'.... I wanna puke.
[...]

Wow, so I'm not the only one?  I've been saying this for, oh, years now? And nobody ever paid any attention.  Every time I see that motto I cringe and feel the creepycrawlies.


T

-- 
Freedom of speech: the whole world has no right *not* to hear my spouting off!

On Thu, Nov 18, 2021 at 08:36:52PM +0000, Adam D Ruppe via Digitalmars-d wrote: [...]
> Think of a fork not as a competing company, but rather as a labor strike.  The goal isn't actually to coexist with nor to vanquish D as we know it today, but rather to save it.
> 
> We'd get together and start a fork with the *goal* of getting the changes merged back upstream and fixing our broken governance model so it never has to happen this way again. Just like how labor unions go on strike to negotiate a better (binding) contract with the company - they aren't leaving their jobs, they are trying to work with the bosses to make their jobs better.
[...]

OK, so the big question: who's "we"?

And who are "we" negotiating with, and what specific result(s) are we
after?


T

-- 
All problems are easy in retrospect.

On Thursday, 18 November 2021 at 22:20:49 UTC, forkit wrote:
> On Thursday, 18 November 2021 at 13:29:59 UTC, Adam D Ruppe wrote:
>>...
>> The truth is really we're in the most stagnant part of D's history right now.
>>....
>
> This is why D needs a new motto. I mean, one that actually motivates.
>
> 'Fast code, fast'.... I wanna puke.

I vote for that "From prototype to production"

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.

On Thursday, 18 November 2021 at 23:19:20 UTC, H. S. Teoh wrote:
> OK, so the big question: who's "we"?

The international proletariat.

> And who are "we" negotiating with

The bourgeois class.

> and what specific result(s) are we after?

The dissolution of all class distinctions.


Duh.


ok fine really it is anyone who wants to see real change in the language vs the leadership. And what want to see is the 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.

Now, what I'd like to see from the steering group is:

1) A new DIP policy that dispenses with the pretensions of grandeur and focuses on getting things done. These aren't Ph.D. theses, they're ways to solicit use cases and associated feature requests and technical analyses from the community. 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.

I would vote for steering committee members who weigh changes with a cost/benefit eye. Some breaking changes are short term pain for long term gain. That's worth it.

2) A radically different approach to Phobos development that is significantly more open than it is now. Phobos is currently where code goes to die. It should be where code goes to thrive among the community. Breaking changes are discouraged, but made when necessary.

I've heard people say the package manager renders the standard library obsolete, but this isn't really true. In fact, I think it might be the opposite: a strong stdlib gives a solid foundation for reliable and interoperable third party packages.

What I'd do is to curate things from the community that can be tested and adopted if need be. Then if there's multiple options, work with the authors to abstract out some common interface into Phobos and get the others to use them. Then other packages can depend on the Phobos interface as users swap out implementations.

But again, the steering group would have the final say. I'd just want them to create a process that can be reliably delegated so it isn't using any particular bottleneck; a decentralized development model of a centralized library. They'd say what they want then they can pull from community work if/when it pops up.

3) The steering group would also have access to the foundation budget for hiring outside consultants when necessary. While this might be programming work sometimes we'd more likely need outside help for things like marketing since we have significant in-house code talent.


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.