On Tuesday, 10 February 2015 at 17:00:18 UTC, Andrei Alexandrescu wrote:
> On 2/9/15 11:28 PM, weaselcat wrote:
>> On Tuesday, 10 February 2015 at 07:17:11 UTC, Dicebot wrote:
>>
>>> At the same time stuff like RefCounted is a mess.
>>
>> +1
>> (Sorry for the noise, just wanted to share the opinion. :) )
>
> One actionable item would be to point at a code fragment and argue "wtf - here's some good evidence". Thanks! -- Andrei

My position isn't as a D developer but as a  (somewhat new) D user attempting to port a C++ library. Many features in D feel unfinished and tons of feature requests sit on the bug tracker. Attempting to port a library that requires a lot of deterministic resource management to D has felt like I've been repeatedly kicked in the teeth. There was an enhancement request from 2009 that got closed by Walter about addressing D's lack of resource management utilities back in November (2014) saying just use refcounted. That would be great if refcounted wasn't half implemented and nearly featureless compared to C++'s shared_ptr.

There was a few bug reports for unique/refcounted (submitted by you IIRC) to address their many issues that have pretty much just sat there and which are far beyond my current D skillset to work on. All while major D developers were working on the website and major D utilities are well - broken.

Addendum, I wrote this on a phone during my commute so I apologize about the lack of specifics and links - I hate mobile typing. :)
Also, I am not blaming anyone for not working on what I deem important in a FOSS project. I use almost only FOSS software and understand that if I want feature X I should submit a PR.

But a lot of my disgruntlement using D has already been summed up in proposed DIPs that rot on the wiki.
I'm probably going to continue using D because I like where it's headed but it would be very difficult for me to recommend it to any colleagues.

Again I apologize for the briefness, I'll try to reply to this later with better details.

On 2/10/15 9:18 AM, H. S. Teoh via Digitalmars-d wrote:
> On Tue, Feb 10, 2015 at 09:13:10AM -0800, Andrei Alexandrescu via Digitalmars-d wrote:
>> On 2/9/15 11:49 PM, Mathias LANG wrote:
> [...]
>>> IMO the agenda ( horribly outdated: http://wiki.dlang.org/Agenda ) is
>>> more important than the vision if you want people to work on a
>>> specific area.
>>
>> I've asked Martin whether we should remove it.
> [...]
>
> I've linked the Vision/2015H1 document to the front page, since
> otherwise it was literally impossible to find it. Perhaps it should even
> replace the Agenda page?

Good idea. I think the Agenda page should stay only if someone commits to maintaining it. Martin? -- Andrei

On 2/10/15 9:44 AM, weaselcat wrote:
> Again I apologize for the briefness, I'll try to reply to this later
> with better details.

Much appreciated, thanks. -- Andrei

On Tuesday, 10 February 2015 at 06:22:51 UTC, Andrei Alexandrescu wrote:
> This proposal is a good example of a cultural lore we should unlearn: high-churn, low-impact changes. https://github.com/D-Programming-Language/dlang.org/pull/896 is another example. Meaning changes with a large surface that rewire vast areas, yet result in only dingy improvements.
>
> The main problem with these is they're easy to argue in favor of. Yes, an aggregate repository will make certain things easier. I'm unclear on the relative advantages and disadvantages, but I have no doubt Dicebot has some good arguments loaded already. On that pull request, yes, searching the language definition separately is a nice thing to have.
>
> Yet, even after executing e.g. the unified repository to perfection and after everything was said and done, we're like... how much better than we were? What pain points did we fix? What is the impact?
>
> Probably something that's neither important nor urgent.
>
> Yet we do have matters that are important and urgent. We want to improve Phobos' take on memory allocation. Yet not one soul is working on RefCounted. Few know even what needs to be done of it. Why? Why are so many of us dedicating so much energy to tweaking what already works, instead of tackling real problems? Problems that e.g. - pardon my being pedantic - are in the vision document?
>
> Don't get me wrong. It's quite likely a unified repo would be nice. As would be a separate directory for the language definition. But it's just not what we should be on right now.
>
> This culture of riding the stationary bike faster and faster must change. We must hop on the real bike and get to pedaling.

I'm the author of that pull request. So I guess maybe I should respond to this.

I understand that it's a pretty large, rather dull change. If everyone's busy with more important things and therefore can't review that monster, then that's how it is.

But I think it's not fair to ask me to work on RefCounted (or whatever) instead. I'm not a major contributor. With the recent focus on the website, I've become more active, but only in that specific area. I can see that reviewer time may be better spent elsewhere. My time, however, wouldn't necessarily be spent on other things D if not on the website. I've kinda slipped into spending more time on it that I'd like to. Doing a little web stuff again has been fun, but when I'm out of ideas for the website, it's probably going to be the occasional (simple) bug fix again.

Also, improving the website is part of The Vision, no? "We aim to improve the brand of the D programming language. Part of that is raising the quality of all D-related materials: website, [...], etc."

On 2/10/15 12:16 PM, anonymous wrote:
> Also, improving the website is part of The Vision, no? "We aim to
> improve the brand of the D programming language. Part of that is raising
> the quality of all D-related materials: website, [...], etc."

Keyword here is impact. We may as well find fit to pull that but it turns out it's too much work for the impact. Thanks for your other work btw. -- Andrei

On 2/10/15 9:16 AM, H. S. Teoh via Digitalmars-d wrote:
> I've been with the open source community for about two decades, and my
> observation is that the thriving ones tend to be the ones where people
> contribute because they want to, rather than because they were told to.
> Of course, that does not preclude leadership and direction -- in fact,
> the most successful projects tend to have people in charge with strong
> leadership skills, but said leadership tends to work best when they
> inspire people to follow them, rather than laying down the law and
> saying you must work on X, Y, Z, otherwise you're not helping The Cause.
> The successful projects also tend to be those where contributions of any
> kind are welcomed, no matter how trivial they may seem to be.

Totally. We're trying to do more of that going forward. -- Andrei

On Monday, 9 February 2015 at 06:33:42 UTC, Dicebot wrote:
> Idea is to create an aggregated repository as part of D-Programming-Language organization which will include other existing ones as a submodules

Imho, git subtree would be a better idea

On 2/10/15 1:45 PM, Luc Bourhis wrote:
> On Monday, 9 February 2015 at 06:33:42 UTC, Dicebot wrote:
>> Idea is to create an aggregated repository as part of
>> D-Programming-Language organization which will include other existing
>> ones as a submodules
>
> Imho, git subtree would be a better idea

That's exactly why I asked for a real investigation that discusses pros, cons, cost, benefits, resulting context, alternatives - as opposed to "well let's do it". -- Andrei

On Tuesday, 10 February 2015 at 17:19:16 UTC, H. S. Teoh wrote:
> leadership skills, but said leadership tends to work best when they
> inspire people to follow them, rather than laying down the law and
> saying you must work on X, Y, Z, otherwise you're not helping The Cause.

This really depends. Human beings are oriented towards "gift exchange", so if you have good social glue between participants and they do things for each other on a personal level they will feel some kind of debt and want to return the "gift". Different social groups have different dynamics and cohesion.

But when the project becomes big and it is difficult to perceive changes that are significant I suppose many will feel that contributions won't matter, because the context is too large. The website was small enough and contributions are visible... so people chimed in.

D/phobos is experiencing constant increasing breadth, but if cutting down the scope is not possible to get backing for you can break it down into smaller units. Units that can be complete and polished in reasonable time.

People need closure/catharsis with a reasonable pace...

> The successful projects also tend to be those where contributions of any
> kind are welcomed, no matter how trivial they may seem to be

Yes, but I don't think it would hurt to map out what is needed and how to go about it. I has to be broken down to a measurable level and then you need to provide designs that are approved.

Implementing a nicely architectured design that is not too big can be fun. Designing and implementing something that will be rejected is not fun... The hardest part to get approved is in the design.

Most successful open source projects follow a ready made design... E.g. reimplementing commercial role models or implementing standards.

On Tuesday, 10 February 2015 at 21:45:49 UTC, Luc Bourhis wrote:
> On Monday, 9 February 2015 at 06:33:42 UTC, Dicebot wrote:
>> Idea is to create an aggregated repository as part of D-Programming-Language organization which will include other existing ones as a submodules
>
> Imho, git subtree would be a better idea

I don't think so.

What are the advantages?

One big disadvantage that I see is that you can't create pull requests to the original repos from subtrees.