2 types of D users, both can live together happily if we adjust

[Mike via Digitalmars-d]

On Thursday, 27 November 2014 at 22:58:33 UTC, Vic wrote:

> The 'real project/core' is where we are ( 
> http://blog.apakau.com/2014/11/cmg-paper ) and we need a stable 
> systems language. From 'real project' people, the people that 
> are in the 'experimental platform' currently *shit* where we 
> eat (as per my D programmers that work for me, D is big and 
> unstable).

Can you be more specific about the instability you are 
encountering?  Are you referring to the changes between releases, 
or problems due to bugs?  And which changes/bugs have you 
encountered that have cause you grief?

> If you are w/ me so far, how big/small should core be?
> *Small enough to be maintained by the size of the team at hand 
> and no larger. *

As I see it, D has a lot of contributors willing to maintain and 
enhance it, but the barrier to entry and learning curve is quite 
high for anything significant.  Therefore, the number of 
contributors that actually make a significant difference is quite 
small.

Also, since it is a volunteer effort, there's really not much 
accountability.  Contributors are free to make significant 
contributions, and then leave the D scene without anyone able to 
maintain their work.  Contributors are also free to do partial 
implementations, and move onto something else without completing 
what they started.

I think anyone wishing to leverage D for a critical project 
should be aware of that, and perhaps D should be more transparent 
about it.  That doesn't mean D shouldn't be used for anything of 
importance, it just means that by using D we enter into an 
implicit contract requiring us to either be willing to become 
significant contributors ourselves, or be willing to partner with 
and fund D's development.

When I first approached D, I had high expectations, and as I 
learned more, I also became disappointed and said a few things I 
this forum I wish I could take back.  I misunderstood the culture 
of this community and how it works, and perhaps I still do.  But 
what is more apparent now is we can't expect to rely on D if 
we're not willing to make significant contributions ourselves, or 
fund its development.  And, while using D is itself a small 
contribution, it's not enough.

> Lets make D core small please. List of things that are core: 
> char arrays.  What else should be core?
> The key question in this tread: how small should core D be to 
> be maintainable and stable? How can it be split?

I would like D core to be small as well, but for different 
reasons:  I would like a nimble language that can be used for 
both the smallest and largest of machines, and let the libraries 
differentiate.  But, I don't think it should be partitioned based 
on the size of D's human resources, partially because that is 
going to fluctuate drastically throughout time.  Rather, the 
division should be made based on architectural and design goals.

You might consider doing what other organizations have done:  
Allocating your D talent to fix the problems you have encountered 
by submitting pull requests, or open issues and place bounties on 
them at https://www.bountysource.com/teams/d/issues.

Regardless, I'd still be interested in knowing, more 
specifically, what problems you're encountering.

Mike