Why not promoting team work?

[Chris via Digitalmars-d]

On Saturday, 14 January 2017 at 02:28:34 UTC, nbro wrote:
> Hi!
>
> I've been following D for at least one year. I like it and I 
> think it's a very good programming language, even though I do 
> not agree with everything it's being done.
>
> One thing that has saddened me is seeing a lot of D's users 
> trying to implement their own library or maybe trying to 
> implement multiple libraries at the same time. Most of the 
> results are very poor because libraries are not
>
> 1. completed
> 2. maintained
> 3. well-written
>
> I've seen comments like "I'm no more maintaining this library 
> because I'm not able to proceed since I do not have the 
> skills". This of course doesn't bring any credibility to the 
> language, to the community, etc. So we see some people trying 
> bring the caravan forward, but I many of these people are not 
> qualified enough clearly, since they do not even have the 
> vision and the knowledge that starting a project like creating 
> a serious GUI or modern IDE is not an easy task, and definitely 
> it won't be a person alone that will create one a decent amount 
> of years that will compete with the most performant ones.
>
> My idea (which is mostly directed to the big names behind D) is 
> that team work should somehow be promoted.
>
> How could you do such a thing?
>
> One possibility could be to announce interesting and useful 
> projects in D and somehow ask for people interesting in working 
> in such projects. These people should clearly be qualified for 
> the job, but this isn't an easy task to verified. The projects 
> could eventually or not be backed up by the announcer of the 
> project.
>
> These could be a few starting ideas and options.

To begin with, an overview of interesting / promising projects 
would help to see what's there, what's good about them (to avoid 
re-inventing the wheel), what's bad about them (to invent a 
better wheel), etc.

The thing is that most of the effort goes into Phobos, language 
features and optimizations. It is hard to keep up with demands in 
these sectors and competition is fierce (Go, Rust etc.). Things 
like GUI libraries are not so important in comparison, as it is 
not hard at all to bind to the millions of C libraries that are 
out there.

I think priorities have changed (yet again). For a language to 
have its own GUI toolkit was important up until say ~2010. Today 
it's common to use bindings to one of the more mature GUI 
toolkits, if you need to (mind you, a lot of programs don't have 
a GUI). Today, language developers have to focus on things like 
concurrency, memory management and useful language features. So 
the core developers will always be busy with that kind of stuff, 
and to get members of the community to work on a big project 
(GUI/IDE) for years is not very realistic. Interests change, 
lives change (kids, buying a house, new job, burn out). In fact, 
with technology being an ever moving target, it might not even be 
wise to put all your money on one big project (especially with 
stuff like IDE/GUI), because you run the risk that a better and / 
or easier options becomes available. Imagine HTML+JS could be 
compiled to native GUI applications on all platforms - with 
native look and feel and graphics - and D bindings were trivial.