My Long Term Vision for the D programming language

[Ola Fosheim Grøstad]

On Tuesday, 16 November 2021 at 21:00:48 UTC, Robert Schadek 
wrote:
> I imagine a DConf where you guys yell at me, not because we 
> disagree,
> but because I'm old and forgot my hearing aid.

Love the intro! :-D

> And if we follow our own project planing, they might just 
> follow along as well.

Just having a plan and showing how it correlates to progress is 
the first box to check in a risk assessment for a software 
project that considers using the language.

But you also need a stable branch and a good versioning scheme 
(no breaking changes between major releases).


>Imagine, a compiler daemon that you start once per
> project/program that keeps
> track of all files related to this project.

Yes, what is needed is a highlevel IR that can be emitted. A 
formal spec of the compilation stages are needed too. It may 
require language adjustments. Speccing what the compiler does now 
will most likely not be what you want.

But it is totally worth it. It will improve the language 
semantics.


> There GC is here to stay, you don't do manual memory management 
> (MMM) in a
> compiler daemon that tracks dependency.
> I don't care how smart you are, you are not that smart.

I think "smart" is the wrong argument. We have to also think 
about costs. So plain MMM is costly, true. But global GC scanning 
does not work well.

Would you be ok with local GC scanning and RC for shared 
references?


> ImportC must have a preprocessor, or it is DOA.

It also has to emulate common GCC extensions :-). Reference 
implementations follow ISO C11, other code often does not.

> This was already partially discussed in the long term goals, 
> but needs better
> documentation or better yet a spec.
> The cool thing is, we don't need to be an ISO spec aka. a pdf.
> We could very well be a long .d file with lots of comments and 
> unittests.

Well, a slow reference implementation that is validating input 
thoroughly is better than just documentation. But then you need 
to streamline the language semantics, otherwise the reference 
will be incomprehensible I think.

But the language would be better if it was done, so not a 
disadvantage. Some breakage would have to be expected.

I you design a high level IR, then you only need to emit that 
from the reference compiler.

> The dart language people shall come to fear our binding 
> generation
> capabilities.

I don't think so. Dart supports live coding. You can modify it 
when the application is running. Anyway iOS/Android are moving 
targets. Too expensive to do well.

> Being a bit dramatic, given people false hope, that gets 
> disappointed, will
> drive them away from D.

Not from D, but maybe from compiler development. But that is a 
big time investment. You cannot expect people to be willing to 
invest so much in an uncertain outcome.


> A simple solution, IMO, is to take clear stance on issues.

Yes. Why invest time in extending the compiler if you don't know 
where D is heading or what is considered a good addition?


> I see the DIP process troublesome as it gives the impression of 
> say of what D
> will become.

Yes. I think a reference compiler would be better. Then people 
can implement what they want and show that as a proof of concept. 
If it is interesting then it will gain momentum.

> I'm serious about the motto at the top.
> When people start complaining that their language is better, 
> its free
> marketing for D.

Ok, I don't think mottos matter much, maybe for the insiders it 
does, but for outsiders it can be seen as childish...

White papers and vision documents matter.

If you have a clear vision, then there is no need for a motto. It 
is self evident.


Kudos again, for taking the time to write a thoughtful and 
*passionate* post! Some changes are necessary, and they will only 
happen if people show their passion. So what yo do here is 
important, I think.