On Tuesday, 11 February 2014 at 21:53:42 UTC, Steven Schveighoffer wrote:
> 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
If you hate too many Ds, then the best name is by far "D flat": D♭

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

> 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?
>

Not sure. That last D looks like a typo...

-Steve

On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:
> I've toyed with this idea for a while, and wondered what the interest there is in something like this.
>
> The idea is to be able to use a subset of D that does not require any of druntime or phobos - it can be linked merely with the C standard library. To that end, there'd be a compiler switch (-betterC) which would enforce the subset.
>
> (First off, I hate the name "better C", any suggestions?)
>
> The subset would disallow use of any features that rely on:
>
> 1. moduleinfo
> 2. exception handling
> 3. gc
> 4. Object
>
> I've used such a subset before when bringing D up on a new platform, as the new platform didn't have a working phobos.
>
> What do you think?

I think a D subset language would be great.

We currently used D in a similar manner at work. Myself and a colleague often use D to prototype C/C++ code and then manually ported it across. The manual port imposes very tight constraints on what we can use from D but it is still better than C.

Even with the manual porting effort it speeds up development. The D compiler catches subtle bugs that creep into C code when deadlines are tight and the porting itself is great as a review process.

Cheers,
ed

ed:

> The D compiler catches subtle bugs that creep into C code when deadlines are tight and the porting itself is great as a review process.

Isn't using something Clang (plus eventually a static analyzer) an even better strategy?

Bye,
bearophile

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.

On Tuesday, 11 February 2014 at 21:11:15 UTC, Walter Bright 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?

-metal

On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:
> I've toyed with this idea for a while, and wondered what the interest there is in something like this.
>
> The idea is to be able to use a subset of D that does not require any of druntime or phobos - it can be linked merely with the C standard library. To that end, there'd be a compiler switch (-betterC) which would enforce the subset.
>
> (First off, I hate the name "better C", any suggestions?)
>
> The subset would disallow use of any features that rely on:
>
> 1. moduleinfo
> 2. exception handling
> 3. gc
> 4. Object
>
> I've used such a subset before when bringing D up on a new platform, as the new platform didn't have a working phobos.
>
> What do you think?

What will this language's niche be? What job is it targeted at? Why would somebody use better C rather than just plain C?

On Tuesday, 11 February 2014 at 22:01:01 UTC, bearophile wrote:
> ed:
>
>> The D compiler catches subtle bugs that creep into C code when deadlines are tight and the porting itself is great as a review process.
>
> Isn't using something Clang (plus eventually a static analyzer) an even better strategy?
>
> Bye,
> bearophile

Absolutely :D

Our main focus has been to introduced D into our workplace. We've been converting a number of old die hard C programmers by showing them how much better the language is, even if one is just writing "C" in D. The bug catching was, however, a pleasant side-effect.

I think the transition to D in the embedded world would be quicker if it were possible to obtain a minimal D language that produces the smallest binaries possible.

Perhaps a good place to start would be with a formal grammar that defines what is the kernel of D and what is the D language proper.

Cheers,
ed

On Tuesday, 11 February 2014 at 22:19:13 UTC, Gary Willoughby wrote:
> On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:

> What will this language's niche be? What job is it targeted at?

My job (realtime embedded Linux).

> Why would somebody use better C rather than just plain C?

If you send me to a C compiler, why bother to evangelize me D? I have C# and Java for all the other uses that are not embedded.

Please, stop telling about "alternatives". It is like taking aways D's very reason of existence.

If is just an application language, it loses. There are better and better-supported out there on the market.

But there is no better systems programming language.

System programming language means being able to write the druntime in it. Without relying on, well, druntime.

If you keep telling "you could use C for that", then, well, I could use C instead of D everywhere, just plain and simple, just as I already do today. In that case, sorry, neither me neither my boss, we are not interested in a Java clone. We don't have space for the virtual machine (oh, call it runtime...).

And, as you say, we could just use C. Or that embedded subset of C++. Speaking about subsets, by the way...

On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:
> The subset would disallow use of any features that rely on:
>
> 1. moduleinfo
> 2. exception handling
> 3. gc
> 4. Object

I think this would kill the usefulness. I've written little D runtimes (doesn't even use the C runtime!) to build working programs that use this stuff and it didn't take a lot of code.

I'd prefer it if the switch ONLY suppressed generation of typeinfo or moduleinfo... and I think there was something else, we have a betterC bugzilla entry that summarized the last discussion.

But still, I'd say it would be better to just not generate some of these things and let the user deal with it. They might manually opt-in to certain things and might not... and I'd say go ahead and leave it as linker errors too.


If we want other stuff to help, do it with the whole D language, for example @nogc has been discussed and might be useful here, while also being useful with the regular druntime.