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