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.
