August 28, 2019
On 2019-08-28 09:05, Eugene Wissner wrote:

> I read this always as "Das better C" too :D

Yeah, D translated into German :)

-- 
/Jacob Carlborg
August 28, 2019
On Tuesday, 27 August 2019 at 15:54:31 UTC, Russel Winder wrote:
> C is a fairly good portable assembler
No its not. C needs a lot of built in compiler macros/functions/extensions to have enough control over generated assembler. But at this time people dont make distinction between a language and compiler provided additions to the language.


September 03, 2019
On Wed, 2019-08-28 at 19:38 +0000, welkam via Digitalmars-d wrote:
> On Tuesday, 27 August 2019 at 15:54:31 UTC, Russel Winder wrote:
> > C is a fairly good portable assembler
> No its not. C needs a lot of built in compiler macros/functions/extensions to have enough control over generated assembler. But at this time people dont make distinction between a language and compiler provided additions to the language.
> 

Fair enough: clearly I should have s/is/was/

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk



September 03, 2019
On Tuesday, 27 August 2019 at 08:06:35 UTC, Walter Bright wrote:
> On 8/26/2019 3:37 AM, Russel Winder wrote:
>> Given there is C and people feel it is time to move on to a better language,
>> and we have D, C++, Rust, and Go as the obvious candidates, there is a problem
>> none of these are actually candidates for the job of replacing C. Even Go,
>> which is supposed explicitly to be C for the 2010s.
>
> I've translated a lot of C code into betterC, and it isn't hard and do not find myself missing anything about C in the process.

I think if we could make this process easy,maybe even automatic that would make it much easier to adopt D.

C2Rust was a DoD project that cost millions I think.  But maybe we could make it an SAoC project next year.  We could use their CBOR dump of the C AST or DMC.

But is it unfair to say D is missing an AST that's pleasant to work with?

I'm not sure whether it would be better to construct a parse tree or AST for this purpose but eg with DPP my personal sense is it would be useful to have a way to generate D code at a more abstract level than strings.

Anyway if you could translate C to D it surely wouldn't hurt.
September 03, 2019
On Tuesday, 27 August 2019 at 17:04:40 UTC, Russel Winder wrote:
> On Tue, 2019-08-27 at 16:07 +0000, Paulo Pinto via Digitalmars-d wrote: […]
>> 
>> The portable Assembly myth of C is long gone in the age of multi-core, pipelined, out-of-order execution units, with NUMA, vector units and GPGPUs.
>
> There is the truth and there is the perception by the masses, which may be the same, but all too often are at odds.
>
> My excuse is that I used C on PDP-11 and VAX-11,

Like this one? :)


https://www.ioccc.org/2018/mills/hint.html
September 03, 2019
On Tuesday, 3 September 2019 at 22:37:04 UTC, Laeeth Isharc wrote:
> I'm not sure whether it would be better to construct a parse tree or AST for this purpose but eg with DPP my personal sense is it would be useful to have a way to generate D code at a more abstract level than strings.

You can always build an AST in objects, then mixin(that_tree.toString()); and let CTFE translate it over. I have used this with various DSL type things in D before, and you could (in theory anyway) do the same thing with full D as well.
September 04, 2019
On Tuesday, 27 August 2019 at 08:08:34 UTC, Walter Bright wrote:
> On 8/26/2019 4:00 AM, IGotD- wrote:
>> The speaker is right about one thing and that is that a systems programming language must not have a runtime dependency, or the runtime is completely OS independent. With this definition this includes C, C++, D (-betterC only) and Rust. As far as I know Go is runtime dependent and does not qualify for this definition.
>
> C++ requires a runtime library that supports exception handling. DasBetterC does not need anything that C doesn't have.

DasBetterC is really quite brilliant. I'm a bit disappointed that so many D fans on this forum react negatively to it.

It would be even better if there were more available libraries built with DasBetterC, like formatted printing, so there is less "roll your own".

I'm sympathetic to Mike Franklin's efforts to make D more "pay for only what you use" but DasBetterC hits a sweet spot now.
September 04, 2019
On Tuesday, 3 September 2019 at 22:44:08 UTC, Adam D. Ruppe wrote:
> On Tuesday, 3 September 2019 at 22:37:04 UTC, Laeeth Isharc wrote:
>> I'm not sure whether it would be better to construct a parse tree or AST for this purpose but eg with DPP my personal sense is it would be useful to have a way to generate D code at a more abstract level than strings.
>
> You can always build an AST in objects, then mixin(that_tree.toString()); and let CTFE translate it over. I have used this with various DSL type things in D before, and you could (in theory anyway) do the same thing with full D as well.

In action: https://youtu.be/HvunD0ZJqiA?t=1216

(shameless plug)

Bastiaan.
September 04, 2019
On 9/3/2019 3:37 PM, Laeeth Isharc wrote:
> But is it unfair to say D is missing an AST that's pleasant to work with?
> 
> I'm not sure whether it would be better to construct a parse tree or AST for this purpose but eg with DPP my personal sense is it would be useful to have a way to generate D code at a more abstract level than strings.
> 
> Anyway if you could translate C to D it surely wouldn't hurt.

This is essentially what AST macros are, a feature that has been repeatedly proposed for D. I've blocked it each time.

The trouble is, it is incredibly powerful. People find themselves unable to resist its siren call, and use it to invent their own language. They never bother to document this language. It winds up balkanizing the underlying language so they cannot share code or even talk to each other.

This doesn't happen overnight, it takes a few years. And then it's too late.

Some examples:

1. Lisp macros
2. Macro assemblers
3. C macro preprocessor
4. C++ expression templates

(3) is a bit of an interesting case. The C macros are very limited in capability, but that barely slowed down the rush to build crazy contraptions with it and embed them everywhere.

I've fallen into this trap myself with both (2) and (3). It took 10+ years of experience to finally realize what a bad idea it was, as it is an enemy of writing understandable, maintainable, reusable, and encapsulated code.

You don't hear much about C++ expression templates these days. For a few years they were quite the darling, until the scope of the horror became apparent.

Think of it like when the devil says you can have anything you want. It seems great for a while, but nothing good comes from it.
September 04, 2019
On 9/4/2019 9:30 AM, bpr wrote:
> DasBetterC is really quite brilliant. I'm a bit disappointed that so many D fans on this forum react negatively to it.

Sometimes I think it is what D should have been in the beginning.