There are 2 users I see, those that see it as an experimental feature platform and those that use it for real projects (and not for experiments).

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).
As I see it, the issue is that D is a wide platform(not a small lang)  that is hard to maintain with the size of the team. (Similar wide platforms feature wise are JRE and CLR, both w/ > 100 developers). So how many core D developers we have?(*)

A more modern language like Go splits btwn stable 'core' and 'experimental feature platform', for example no need for core to have try/catch, when it can be done downstream:
 - http://github.com/manucorporat/try
This is similar to Linux: kernel and gnu; and what I propose for D: to be split up.

This would allow users of *real project* to use a core and people that want to have  features could do that downstream: let a 1000 flowers bloom!

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

Something stable for us to lean on.
Next, is it feasible to split? Std library has much bloat and is easy to split up into core and downstream experimental feature platform.
That leave the compiler. I am not an expert, but this could be done w/ core 'compiler' and the rest in optional pre-processor. I think it can be done w/ backwards compatible (just switch GC to default off)

I'll say 90% +  should and must be moved to downstream projects. This allows for the famous quote: 'fearlessly peer into the gates of hell’ - all I’m saying do it downstream, let us build projects that can lean on small/simple and maintainable D core.

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?

http://tinyurl.com/q5t2eag

On Thu, Nov 27, 2014 at 10:58:31PM +0000, Vic via Digitalmars-d wrote:
> There are 2 users I see, those that see it as an experimental feature platform and those that use it for real projects (and not for experiments).
[...]

The thing is, based on my observations over the past few years or so I've been here, such grand plans have often been proposed (in the best of intentions, to be sure) but rarely carried out. The thing about D is that if you wish to see something happen, you just have to dig in and *do* something about it. Be the champion of whatever you propose, get on the ground and work it out, make it happen. Contribute code. Help improve the infrastructure. Be the change you wish to see take place.

While these forums can be quite entertaining, from my observations most of the animated discourse ultimately results in nothing -- because nobody actually got up to *do* something about it. The stuff that *does* happen often happens in the background where somebody actually did the hard work and wrote the code, pushed the PR's through to acceptance, contributed the hardware to improve the infrastructure, etc., often with little or no activity on the forums.  Almost all of the discussions on the forums that have little or no code backing it up tend to just sputter out after everyone's energy has been exhausted, and nothing happens.

So, if you wish to see the changes you propose, I'd say your best bet is to start *doing* something about it (besides talking about it on the forum, that is). Remember that this is an open source project with contributions made by volunteers; telling volunteers what to do with their free time rarely works. Contributing real work, OTOH, tends to catch people's attention much more effectively.


T

-- 
The most powerful one-line C program: #include "/dev/tty" -- IOCCC

Isn't this the purpose of std.experimental?

I completely understand and support the DIY nature of Open Source and it's something that should be underlined often!

If we turn out to be successful, I  do plan to resource out D support. But I'm running a startup and don't have the spare cycles. But I am using D, betting the company on it, programmers in my shop do D 100% of time, so I do consider myself a part of the D community.
So all I can do is wish for a small and stable D lang, vs a large D experimental platform - and both are possible. If I had resources I would divide Phobos and complier/pre-compiler to support the 2 camps: people that use D on real projects and people that want to experiment as I have outlined.
I do think this to be key thing for the active D community to internalize as it relates to D wide adoption or disappearing: the size of project managed as it releases to FTE (~2000 hrs/year) resources that maintain it. Manifested mostly as http://en.wikipedia.org/wiki/Feature_creep or instability (is my code wrong or is it D )


On Thursday, 27 November 2014 at 23:24:59 UTC, H. S. Teoh via Digitalmars-d wrote:
> On Thu, Nov 27, 2014 at 10:58:31PM +0000, Vic via Digitalmars-d wrote:
>> There are 2 users I see, those that see it as an experimental feature
>> platform and those that use it for real projects (and not for
>> experiments).
> [...]
>
> The thing is, based on my observations over the past few years or so
> I've been here, such grand plans have often been proposed (in the best
> of intentions, to be sure) but rarely carried out. The thing about D is
> that if you wish to see something happen, you just have to dig in and
> *do* something about it. Be the champion of whatever you propose, get on
> the ground and work it out, make it happen. Contribute code. Help
> improve the infrastructure. Be the change you wish to see take place.
>
> While these forums can be quite entertaining, from my observations most
> of the animated discourse ultimately results in nothing -- because
> nobody actually got up to *do* something about it. The stuff that *does*
> happen often happens in the background where somebody actually did the
> hard work and wrote the code, pushed the PR's through to acceptance,
> contributed the hardware to improve the infrastructure, etc., often with
> little or no activity on the forums.  Almost all of the discussions on
> the forums that have little or no code backing it up tend to just
> sputter out after everyone's energy has been exhausted, and nothing
> happens.
>
> So, if you wish to see the changes you propose, I'd say your best bet is
> to start *doing* something about it (besides talking about it on the
> forum, that is). Remember that this is an open source project with
> contributions made by volunteers; telling volunteers what to do with
> their free time rarely works. Contributing real work, OTOH, tends to
> catch people's attention much more effectively.
>
>
> T

On Thursday, 27 November 2014 at 23:24:59 UTC, H. S. Teoh via Digitalmars-d wrote:
> *do* something about it. Be the champion of whatever you propose, get on
> the ground and work it out, make it happen. Contribute code. Help
> improve the infrastructure. Be the change you wish to see take place.

Sound advice if you want a single feature, but this does not work for restructuring and management. You cannot "commit" people into moving in the same direction, you need to create common ground. That takes time if there is no skilled leader to pull it through.

> While these forums can be quite entertaining, from my observations most
> of the animated discourse ultimately results in nothing -- because
> nobody actually got up to *do* something about it.

I disagree, intelligent people pick up the arguments even though they may not like them at the time they face them. These arguments eventually move up through their brainstem if they are good at learning (I think most programmers are good at that). By iterating over the most problematic issues you get many viewpoints and a new direction might emerge over time (measured in years, not weeks).

The @nogc focus got in by "external" advocacy. It did take some noise, but it got in.

> So, if you wish to see the changes you propose, I'd say your best bet is
> to start *doing* something about it

In this case it actually means refactoring the compiler codebase, which will by necessity lead to a fork if this is not wanted by the main developers as it will break up their existing mental model of the program.

On Friday, 28 November 2014 at 00:19:49 UTC, Ola Fosheim Grøstad
wrote:
> The @nogc focus got in by "external" advocacy. It did take some noise, but it got in.

It took a lot of noise and IMO rust removing their GC to force
something to happen.

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

On Friday, 28 November 2014 at 00:17:19 UTC, Vic wrote:

> So all I can do is wish for a small and stable D lang, vs a large D experimental platform - and both are possible. If I had resources I would divide Phobos and complier/pre-compiler to support the 2 camps: people that use D on real projects and people that want to experiment as I have outlined.

You are not leveraging all of phobos or druntime, right?  What is the minimal amount of D that you need?  With that scope in mind, you may find that it would require minimal resources in time or funds to fix the issues that you are encountering.  Again, without knowing what those issues are, no one can say.

Mike

On Thursday, 27 November 2014 at 22:58:33 UTC, Vic wrote:
> There are 2 users I see, those that see it as an experimental feature platform and those that use it for real projects (and not for experiments).
>
> 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).
> As I see it, the issue is that D is a wide platform(not a small lang)  that is hard to maintain with the size of the team. (Similar wide platforms feature wise are JRE and CLR, both w/ > 100 developers). So how many core D developers we have?(*)
>
> A more modern language like Go splits btwn stable 'core' and 'experimental feature platform', for example no need for core to have try/catch, when it can be done downstream:
>  - http://github.com/manucorporat/try
> This is similar to Linux: kernel and gnu; and what I propose for D: to be split up.
>
> This would allow users of *real project* to use a core and people that want to have  features could do that downstream: let a 1000 flowers bloom!
>
> 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. *
>
> Something stable for us to lean on.
> Next, is it feasible to split? Std library has much bloat and is easy to split up into core and downstream experimental feature platform.
> That leave the compiler. I am not an expert, but this could be done w/ core 'compiler' and the rest in optional pre-processor. I think it can be done w/ backwards compatible (just switch GC to default off)
>
> I'll say 90% +  should and must be moved to downstream projects. This allows for the famous quote: 'fearlessly peer into the gates of hell’ - all I’m saying do it downstream, let us build projects that can lean on small/simple and maintainable D core.
>
> 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?
>
> http://tinyurl.com/q5t2eag

While all this may be true, why does the code base need to be split for you to use the core, ie can't you just stay away from new and experimental features of the language?  Perhaps you don't know the age or level of stability of each feature, but it strikes me that starting a project to document that would be much easier than trying to push a split.

Yes, that is one example of something that could be a downstream feature with alternative implementations.

On Friday, 28 November 2014 at 01:29:16 UTC, weaselcat wrote:
> On Friday, 28 November 2014 at 00:19:49 UTC, Ola Fosheim Grøstad
> wrote:
>> The @nogc focus got in by "external" advocacy. It did take some noise, but it got in.
>
> It took a lot of noise and IMO rust removing their GC to force
> something to happen.