On 2/11/14, 12:56 PM, Brad Anderson wrote:
> On Tuesday, 11 February 2014 at 19:59:26 UTC, Frustrated wrote:
>> D should have a core language subset that is essentially what you
>> describe above. This allows it to be used at a lower level. Call
>> it embedded D if you want. Other names:
>>
>> D core, D*, D lite, D-, Dm, @D, D^c(D with a c superscript = D
>> core), etc...
>
> How'd you overlook D--? :P

No new name please. It would be among the worst things to do right now.

Andrei

On 2/11/14, 1:10 PM, Walter Bright wrote:
> On 2/11/2014 12:53 PM, Steven Schveighoffer wrote:
>> I think you overestimate the size of this project.
>
> I agree it's not a big deal. It's just implementing a switch that
> disables a list of features. The switch even already exists, though it
> is incomplete.
>
> The payoff is the embedded market is huge, and this can greatly expand
> D's presence in the marketplace.

It's yet another opportunity to waste focus. (But then it goes to prove that everybody does what they want...)

Andrei

On 2/11/2014 1:34 PM, Francesco Cattoglio wrote:
> Do you think it would be easier to create this after having switched to "DDMD"?

That wouldn't make it either harder or easier.

On 2/11/2014 1:28 PM, Peter Alexander wrote:
> Is it really worth taking effort away from D2 when so much is left to do there?

The "worth it" issue is does it expand the user base of D relative to the effort? I'd say yes.

On Tuesday, 11 February 2014 at 21:28:15 UTC, Peter Alexander wrote:
> On Tuesday, 11 February 2014 at 21:22:40 UTC, Walter Bright wrote:
>> snip
>
> Thank you, so this project would need to be maintained alongside D2 development, just like D1 was.
>
> Is it really worth taking effort away from D2 when so much is left to do there?

A few if() blocks and some code to parse a command-line option is hardly a "project" that needs to be "maintained alongside D2 development".

However, I agree that there are better things the core compiler maintainers could do with their time. I think such a switch would be easy enough to implement and maintain by whoever needs it.

On Tue, 11 Feb 2014 16:11:19 -0500, Walter Bright <newshound2@digitalmars.com> wrote:

> On 2/11/2014 11:43 AM, Walter Bright wrote:
>> (First off, I hate the name "better C", any suggestions?)
>
> How about "EmbeddedD", though that wouldn't be entirely accurate?

Sorry, WAAAY too many D's :)

-Steve

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.

I'd say that "D as a Better C++" would have merit. Those would wanted to avoid classes could do so, so you'd have already achieved "D as a Better C" by doing it, without having to product a different language reference. Point in fact, there shouldn't be any difference in the language references other than that in the GC-less variant, you have to call "delete" to free memory, do some extra magic to work with ranges, and Phobos isn't included.

On 2/11/14, 3:41 PM, Andrei Alexandrescu wrote:
> On 2/11/14, 1:10 PM, Walter Bright wrote:
>> On 2/11/2014 12:53 PM, Steven Schveighoffer wrote:
>>> I think you overestimate the size of this project.
>>
>> I agree it's not a big deal. It's just implementing a switch that
>> disables a list of features. The switch even already exists, though it
>> is incomplete.
>>
>> The payoff is the embedded market is huge, and this can greatly expand
>> D's presence in the marketplace.
>
> It's yet another opportunity to waste focus. (But then it goes to prove
> that everybody does what they want...)
>
> Andrei

It's analogous to estimating the cost of any other new feature.  It's far more than the cost of just the implementation.

I don't disagree with doing it, not at all, but also have a concern with under estimating the costs.

On 2/11/2014 1:53 PM, Steven Schveighoffer wrote:
> On Tue, 11 Feb 2014 16:11:19 -0500, Walter Bright <newshound2@digitalmars.com>
>> How about "EmbeddedD", though that wouldn't be entirely accurate?
>
> Sorry, WAAAY too many D's :)

That's a Good Thing (tm), isn't it?