D as A Better C?

[Brad Roberts]

On 2/11/14, 3:54 PM, Frustrated wrote:
> I believe this is the wrong way to think about it. It is not
> creating a new language, creating new features, or anything. It
> is simply partitioning the language feature set into two parts,
> one that works on more systems, is easier to implement by others,
> easier on the compiler, debuggers, and whole tool chain and
> requires virtually nothing but a little time going over the d
> language spec and saying "This goes goes in this bin, that goes
> in that bin" then have it reviewed.
>
> This is really at this point just saying what the core part of
> the spec is. Which is a subset of the language spec, nothing new,
> very little work to be done, opens up the floodgates for people
> to get it moving. It's actually counterproductive to hold it off
> as you are putting the breaks on D becoming used by more people.
>
> If you create an embedded systems level core(which is just saying
> that it works well in embedded systems, which generally require
> lower overhead) now then people can get it moving now.
>
> You don't even need a compiler for it at this point. Just create
> the subset language spec(easy peasy), put it out there, get some
> interest on it, then let others write it for you(by forking the
> compiler, making the changes that are require(which is removing
> code rather than adding in most cases)).
>
>
> If you wait 5 years for this then that puts D 5 years behind in
> the embedded systems and 5 years that people could have been
> working on it.

That's a very incomplete view of the work required.  If it's a formal 
part of the design of the language, then it requires far more than just 
a tiny bit of compiler work.  It requires a rework of the docs, and not 
just a tiny rework.

If all we do is a surface level execution, we'll have only muddied up 
the spec and the language even further, not clarified and simplified 
anything.  This is a recurring problem with almost every change to D. 
It's maybe half executed on.  And this would be conceptually a very 
large split, even if small at the compiler level.