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

[Vic via Digitalmars-d]

inline:

On Friday, 28 November 2014 at 05:14:31 UTC, Mike wrote:<snip
> 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.

  I say there is very few.  I have to challenge your data that 
there is a lot of contributors. Most projects list their 
maintainers, what is the number of FTE D maintainers?

That is a loaded question of course, relative to surface area:
http://dlang.org/comparison.html
of sacred cows relative to FTE maintainers.


> 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.
>

How much $ funding so I consider it?
For example for regressions to be done but only for core. (none 
of silly things, which is a long list of GC, AssociaveArrays, 
demangle, annotations, higher order functions, pseudo members, 
transmogrify, goto, try/catch, vardic, traits, variant, sqllite, 
etc. I am not saying to remove them, just make them downstream 
like GNU does, not part of regression tested D core.  If I wanted 
to use a big lang I'd do CLR or JRE.


> When I first approached D, I had high expectations, and as I 
> learned more, I also became disappointed

Yes, that is the pattern. Come in, and leave. There has to be 
more people staying and more D shops (like my shop is pure 100% D 
).
The regressions are painful, and I propose a way to let people 
experiment and compete on rich features. My proposal is to make a 
small stable core that can be maintained, so that people say.

> 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.

The culture of the D contributes is 'to bravely peer into gates 
of hell' - as in experiment. As user of D I want it to be small, 
stable and maintained. I proposed a path that allows for both, 
w/o scaring of people that use D for real projects. If that is 
not so, then I missed that D is an experimental language.

>
> 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

My problem: I have 3 developers(still hiring more) that work for 
me please lets not use D, it is not stable release to release 
(and has a bunch of things no one needs).
I told them: we are a D shop because long term I anticipate D and 
Walter to succeed.
So I hope that maintainers consider users of D and not chase them 
away.
Vic