D as A Better C?

[Frustrated]

On Tuesday, 11 February 2014 at 21:39:19 UTC, Andrei Alexandrescu
wrote:
> On 2/11/14, 12:47 PM, Peter Alexander wrote:
>> On Tuesday, 11 February 2014 at 20:02:37 UTC, Frustrated wrote:
>>> On Tuesday, 11 February 2014 at 19:56:11 UTC, Peter Alexander
>>> wrote:
>>>> On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright 
>>>> wrote:
>>>>> What do you think?
>>>>
>>>> I think it would have little benefit and would just lead to 
>>>> pointless
>>>> fragmentation and maintenance for the compiler devs.
>>>
>>> Do you program on embedded systems? If not then do you think 
>>> you
>>> are qualified to say it would have little benefit or not?
>>
>> I do program on embedded systems.
>>
>> I'll elaborate more on why I think this is a bad idea.
>>
>> First, we are struggling immensely as it is to get D2 into a 
>> complete
>> state. Many parts of the language are still poorly defined and 
>> even more
>> poorly implemented. The standard library is still lacking in 
>> critical
>> areas and there are still thousands of non-trivial bugs in the 
>> database.
>> The language itself is still evolving rapidly. Speaking 
>> optimistically,
>> I think we are still a few years away from resolving the 
>> existing
>> language issues, based on the current pace of things.
>>
>> We're heading in the right direction now and even 
>> accelerating, but I
>> think it would be incredibly unwise to embark on a new 
>> side-project,
>> which would just consume dev time, pulling effort away from D2
>> development. D1 was discontinued to spend more time on D2, not 
>> to start
>> new projects of debatable benefit.
>>
>> Please let's finish this language before we start on another.
>
> I agree. Walter, let's put that on the backburner. Thanks.
>
> Andrei

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.