On Thursday, 9 February 2017 at 16:48:16 UTC, Joseph Rushton Wakeling wrote:
> There's clearly in part a scaling problem here (in terms of how many people are available in general, and in terms of how many people have expertise on particular parts of the library) but it also feels like a few simple things (like making sure every PR author is given a reliable contact or two who they can feel entitled to chase up) could make a big difference.

Regarding the scaling problem - Perhaps the bug system could be used to help engage a wider community of reviewers. Specifically, update the bugzilla ticket early in the PR lifecycle as an alerting mechanism.

This idea comes from my experiences so far. I've found any number of bugs and enhancements in the bug system that directly interact with things I'm implementing. I typically add myself to CC list so I hear about changes. In many of these cases I'd be willing to help with reviewing. However, when a PR associated with the issue is created, the ticket itself is normally not updated until after the review is finished and the PR closed, to late to help out.

Of course, someone like myself, a part-timer to the community at best, should not be a primary reviewer. However, for specific issues, it's often the case that I've studied the area of code involved. If there is a wider set of people in a similar situation perhaps this might help engage a wider set of people.

--Jon

On 2/9/2017 1:06 PM, Joseph Rushton Wakeling wrote:
> On Thursday, 9 February 2017 at 20:43:00 UTC, Walter Bright wrote:
>> *Anyone* in this community can step up and do that.
>
> Anyone can make observations and proposals, but not everyone has the authority
> to effect change.

Anyone can proactively look at, review, analyze, etc. any PR.


> I appreciate how frustrating it must be to have people saying, 'Hey, do this!
> Do that!' without necessarily volunteering their own efforts in support, but
> organizational improvements so very often fail unless they are eagerly pursued
> at a leadership level.

There are 29 people with commit privileges on Phobos:

  https://github.com/orgs/dlang/teams/team-phobos

What do you suggest? What are you willing to step up and do?

On 2/9/2017 1:45 PM, Jon Degenhardt wrote:
>However, when a PR
> associated with the issue is created, the ticket itself is normally not updated
> until after the review is finished and the PR closed, to late to help out.

It normally is. I do it for all mine and for others I notice that have not so.

On Thursday, 9 February 2017 at 17:28:47 UTC, jmh530 wrote:
> I would probably say libraries is most important. Mir is a great advance. I've been applauding your work all the way through. There are two things that I think Mir needs most (and we've talked about them before as things you were thinking about) and then a third is a nice-to-have
> 1) A higher level layer with more convenient syntax for Mir-Glas
> 2) Lapack support (eigenvalues, svd, & cholesky/qr decompositions)
> 3) D compute support (would be nice to easily offload big computations to GPU)

number 3 is in the pipeline. LDC should be able to produce .ptx and .spv (the intermediate formats for CUDA and OpenCL respectively, with host code all at the same time!) RealSoon™ (I hope by the end of the month).

From there it's all just plain D API bashing, which will be easily automated with .mangleof and templates.

I am hoping to give a DConf talk about this.

On Thursday, 9 February 2017 at 17:45:15 UTC, Nick Sabalausky wrote:

> No. There should be appropriate checks and reviews, yes. But, no, every little fix and improvement shouldn't feel like trying to get somewhere in a year-long tabs vs spaces debate or making a big-budget sales pitch to Indecisives Anonymous.

Yep! There are currently 165 poor sinners in DMD PR purgatory.  The oldest is going on 5 years, waiting on someone to make a decision whether to use "-version", "-versions", "-dversion", or "-version=?".  Then, it would have to be rebased, and languish again for another indeterminate amount of time.  I wouldn't be at all surprised if the original contributor has moved on; I would have 4 years ago.

Mike

> 1. Why your company uses  D?

My company does not use D. If I had the time, I really think I could integrate D into our build system, probably forcing it a bit: "Oh and by the way, that new library I wrote happens to be written in D..." (We have Vala in our build system, how worse could it be?).

I use it for personal projects.

> 2. Does your company uses C/C++, Java, Scala, Go, Rust?

We use C/C++/assembly for system stuff. And Java for Android applications. We run Linux or Android on ARM embedded systems.

> 3. If yes, what the reasons to do not use D instead?

Nobody knows about D. Most system developers use C here, half of them don't like C++ and scorn Java. And most of them don't know about D apart from my close colleagues which probably must hate it without having even used it, just because I always bring it up in any unrelated conversation at lunch.

> 2. Have you use one of the following Mir projects in production:

No, but it could be very useful for DSP routines. I hope Mir (and D) to have the success it deserves.

> 4. Have you use one of the following Tamedia projects in your production:

No.

> 5. What D misses to be commercially successful languages?

I don't know, I'm not a sales-person at all.
I also like D because it's got that "made by developers for developers" thing. I'm an idealist, I'd prefer D to be successful because of its cheer intrinsic value as a programing language, rather than because we throw big money at it.

> 6. Why many topnotch system projects use C programming language nowadays?

For history reasons. And because of its simplicity (and tooling etc), and its "system" trait.
I don't buy the "C compiles bugs" argument. Every languages in the world produce bugs [1].

I noticed the hardest and most insiduous bugs could always be avoided if the software was more carefully designed upfront, especially for real-time or concurrent software.

I use C a lot, it's my favorite language with D, though I'm not a proselyte. I use C++ only as "C with class".

[1] http://jonathanwhiting.com/writing/blog/games_in_c/

On Wednesday, 8 February 2017 at 18:27:57 UTC, Ilya Yaroshenko wrote:
> 1. Why your company uses D?

The only other real alternative (everyone using it) in my field was C++, and I have worked in a variety of C++ codebases. For me it's not a productive language and lead to inflexible programs that I don't even like. However, this is subtle enough that you don't see it while on the job.

Was it risky to choose D? I don't think so, especially when the less risky choice is costing precious productivity day to day.


> 2. Does your company uses C/C++, Java, Scala, Go, Rust?

Only D. I fear of becoming monoglot programmer. :)


> 3. Have you use one of the following Mir projects in production:
> 4. Have you use one of the following Tamedia projects in your production:

Nope.


> 5. What D misses to be commercially successful languages?

Targetting iOS or Web would be nice.

Other than that, I think we need to "reframe" the competition who easily took a moral high-ground against us (not mentionning D, saying it's old, etc) and repeat our key advantages: D is productive, fast, already there (no vapor) and you _kind of already know it_(yeah, kind of). Being familiar is key to cater to C++ people - a difficult and busy audience.

Rust has convinced people that they don't want a GC, it is the most common argument against D. _It does not make any goddamn sense_ considering the number of real-time systems with no GC problem.

So why people don't even think they could try D? I think it really is a cool kid thing, D should present itself as evergreen, and not an "old" thing.



> 6. Why many topnotch system projects use C programming language nowadays?

Because of when they were created?
Those that haven't been replaced by topnotch systems in C++ (and in language X later, hopefully X = D).

On 2/8/17 7:27 PM, Ilya Yaroshenko wrote:
> 1. Why your company uses  D?
>
>   a. D is the best
>   b. We like D
>   c. I like D and my company allowed me to use D
>   d. My head like D
>   e. Because marketing reasons
>   f. Because my company can be more efficient with D for some tasks then
> with any other system language
>

Will probably stop on this question as the rest is not applicable.
I do not use D at my company and the reason is that any language to get a use need to pass stringent sorting criteria that I don't even appreciate fully. The language that have green light I believe are

C++, Go, Java, Python (under heavy pressure to switch to Go)

Anyhow when trying to sell D to any company the only case I can make a good offer is having these attributes:

1) It's a new project, not extension of an existing behemoth code base
2) Fairly unique - i.e. cannot be just a bunch of existing libraries glued together with some business logic.
3) Needs native performance at least in some areas of the project.

Now let's imagine a company considers technology X and I want to propose D instead. Let's look at possibilities:

C++ - they are not afraid of creating their own stack and performance-minded. This is probably the only case where selling D is easy. However these days selling them Rust would be much easier.

Rust - they value native speed, safety and afraid of GC. D's state of GC would only confirm their fears and D's safety is mostly opt-in/ relies on GC/not supported enough.

Java - they love VM safety and GC, most likely invested in Java ecosystem. Here the better sell would be Scala or Kotlin etc.

C# - they are probably hooked on MS technology and tooling (VisualStudio). The current state of D's IDE will make them cry like little babies, no selling here.

Go - they value simplicity and robust run-time (Go's GC breaks news with sub-milisecond pauses on large heaps). The sheer complexity of D is enough for it to be a hard sell, D's GC is coup de grace.

Scripting languages - they don't care for elaborate type systems and willing to trade performance for flexibility. Selling easy templates to them is like giving candies to kids with diabeties. Trying to lure with performance hits a brick wall because e.g. NodeJS/LuaJIT have fast JITs already and they don't care going beyond that level.

---
Dmitry Olshansky

On Thursday, 9 February 2017 at 23:44:31 UTC, Walter Bright wrote:
>> I appreciate how frustrating it must be to have people saying, 'Hey, do this! Do that!' without necessarily volunteering their
>> own efforts in support, but organizational improvements so very
>> often fail unless they are eagerly pursued at a leadership
>> level.

Before I respond, just wanted to say: I hope the above didn't come over as a personal attack, it wasn't meant as one.  I was speaking in general about my experience of what can best influence change.

> There are 29 people with commit privileges on Phobos:
>
>   https://github.com/orgs/dlang/teams/team-phobos
>
> What do you suggest? What are you willing to step up and do?

I'm painfully aware that I have limited ability to commit time and energy right now.  I think that's one reason have been pushing this discussion: because my time is limited, when I _do_ find time to craft some code and send it to Phobos or elsewhere, it's quite precious to me, and I try to take a lot of care over it.  It's not very nice to feel that this time is wasted because no one is paying attention to the results, and it's not very nice to feel that this is a situation that is just accepted.

So, that said, what would I suggest?  Well, 29 people with commit privileges is less than 4 currently-open PRs per person.  Let's be conservative and suppose 10 of them are regularly active.

What I would suggest is it takes one or two people with authority (important caveat, more on this in a moment) to periodically nudge those 10+ people about any PRs that (i) do not have an assigned reviewer with commit rights or (ii) do have an assigned reviewer but haven't had any activity in more than, say, 2 weeks.  This doesn't need to be orders (impossible in a volunteer project) -- just encouraging requests for help and awareness-raising to make sure that no PR falls behind.

Then in turn, the 10+ people with commit rights need to be actively encouraging appropriate people to review the PRs they are responsible for, with the sense that it strongly matters that no PR author feels they're being abandoned (a feeling which needs to be encouraged by the top people: if the people with commit rights aren't nudging the reviewers on a particular PR, they need to be nudged themselves).

The authority bit matters because the one or two people at the top need to be able to field the questions that the 10+ with commit rights can't decide for themselves -- in a way that helps them understand the principles behind those decisions so that they can apply them themselves, confident that they're not going to be knocked back if the apply the same principles in future.

Basically, the role of the senior authority figure here is to support the people with commit rights in learning how to make decisions which won't need to be countermanded.  No one person scales, but 10 people who understand 95% of that one person's thought _can_ -- and they can pass on that understanding to others.

Of course, I understand that I might be suggesting things that have been tried and have not worked out.  But you asked for my suggestions, so ... that's what seems important to me.

On Friday, 10 February 2017 at 23:02:38 UTC, Dmitry Olshansky wrote:
> Go - they value simplicity and robust run-time (Go's GC breaks news with sub-milisecond pauses on large heaps). The sheer complexity of D is enough for it to be a hard sell, D's GC is coup de grace.

I have never understood the appeal of Go. With respect to the GC, there's this: https://blog.plan99.net/modern-garbage-collection-911ef4f8bd8e#.o6pxesvuw

With respect to "simplicity", I found it to be easy to learn a language that makes it hard to get stuff done. I've never understood the argument that programming in Go is simple. Clearly others have their own view.