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
