On Friday, 28 November 2014 at 20:00:36 UTC, Vic wrote:
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?
You can see the lists here:
https://github.com/D-Programming-Language/dlang.org/graphs/contributors
https://github.com/D-Programming-Language/dmd/graphs/contributors
https://github.com/D-Programming-Language/druntime/graphs/contributors
https://github.com/D-Programming-Language/phobos/graphs/contributors
There's not going to be a high FTE count because D is a volunteer
effort with, from what I can tell, no significant financial
support. This is not a secret and users should be aware of this
when they choose to use D. As I said in my previous post, IMO,
users should expect to either contribute programming talent or
funds if they intend to use it for anything critical.
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.
Can't the features that you don't need just be ignored? The .Net
Framework is HUGE, but that doesn't prevent me from using a very
small subset of it for my work.
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.
Do you have a bugzilla issue for each of the regressions you're
referring to? The regressions that I see listed here
(http://wiki.dlang.org/Beta_Testing#Available_Downloads) are
quite small in number, and arguably in code that is rarely
employed.
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.
I don't see D as an experimental language. "Experimental"
implies it's trying features that may or may not work, and is
trying to see how they pan out. From what I can tell, the vast
majority of D's features are borrowed from other time-tested,
proven languages, and the D specific features that I've employed
have been powerful and liberating.
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).
1) Not stable release-to-release?
Which regressions? Please provide links to the bug reports.
Without these, there's nothing actionable, and you're argument
against D is questionable.
Ask your developers for something specific and actionable. You
may be pleasantly surprised by the helpfulness of this
community...or not.
2) has a bunch of things no one needs...
The things you don't need don't need to be employed.
This seems to be your fundamental premise: Because D is a
feature rich language with limited resources, resources are
spread too thin making D unmaintainable with the resources it
has. I'm not convinced. First of all, that doesn't appear to be
how this effort works. There isn't a CEO setting priorities and
cracking a whip over contributors' heads. Contributors largely
work on those things that interest them. Second, if D were to
move non-core features downstream, the contributors that work on
those features will also move downstream, thinning D's core
resources even further.
If regressions are the problem, please file bug reports and bring
them to this community's attention. You may find some helpful
people willing to address them for free simply because it
interests them or it was something they were meaning to get to,
and just needed a little motivation. If there isn't anyone
willing to address them, the problem could potentially be
monetized.
Mike
