On Friday, 6 May 2022 at 06:57:52 UTC, Siarhei Siamashka wrote:

Yes, you have som points here.

The total development overhead of meta programming is costly if you don't write libraries that are reused in multiple projects. So in order to reap the benefits of having advanced meta programming in a language you need a community that builds libraries for reuse. In D that primarily means the standard library as the number and quality of third party libraries is limiting in comparison with more mainstream languages.

This could be improved by having a smaller stable standard library and in addition have a set of curated libraries that are more open to evolution.

As it is, D cannot capitalize on metaprogramming features, because the eco system for building reusable components isn't there.

If you have an unchanging external library and an advanced compiler then it could cache some of the work done for reuse to lower the compilation times.

This could be improved by having a strategy where the focus was on building a more modular compiler rather than adding more features to the existing one.

D is where it is because of management choices made (or not made), I think. Overall, D is not as popular as it could be because there are missing bits and pieces, both in the language/implementation and the approach to the eco system.

The solution to this could be:

1. Simplify syntax and semantics, clean it up with a focus on ease of use. Full feature freeze until this is done.

2. Create a compiler infrastructure that is modular where contributors can contribute in focused areas without understanding the whole thing.

3. Reduce the core standard library to something that is stable and can be evolved to be of the highest quality. Then move auxillary stuff to official support-libraries where breaking changes are more accepted (with semver support so you still can use an older version).

4. Map out the missing bits in documentation and official support-libraries that hampers productivity.

With no such clear strategy, nothing will change.

On Friday, 6 May 2022 at 07:58:06 UTC, Paolo Invernizzi wrote:

Let us put this in perspective first.

Using templates for computations was not something the C++ designers wanted to support. In general, allowing programmers to execute recursion/loops at compile time is a serious liability for large projects.

1. In general, language designers want the compilation to execute in O(N) where N is the length of the source code.

2. There is no good solution to debug what goes wrong, so it certainly creates complications!

Those are two very good reasons for not adding CTFE.

Now, in C++ CTFE was inevitable because they have a large third party eco system where people started to use templates this way and it was becoming a language problem. So basically, it is a byproduct of a significant mistake in their original template design combined with having a large eco system of reusable code (libraries).

Basically, they had no choice, but to add it. When C++ adds it, there will be more demand for it because many programmers know what C++ has.

On Friday, 6 May 2022 at 08:19:38 UTC, Ola Fosheim Grøstad wrote:

D need to pay more attention to the development of library.

It is even more important to pay more attention to libraries than the d language.

Look at Python, because they have many libraries, they are developing very well!

On Friday, 6 May 2022 at 08:52:16 UTC, zjh wrote:

D has many libraries that end up not being maintained, so the most important thing is to retain users, and then one needs to understand why they leave. One key issue that has been mentioned in this thread is that people leave because of inconsistencies in the language.

Or maybe the other way around, because the language has aimed for clean semantics and syntax in addition to being stable they get many libraries…

On Friday, 6 May 2022 at 09:37:24 UTC, Ola Fosheim Grøstad wrote:

Yes, what we need is to start D3 where the language can evolve and people can tinker around more. D2 isn't going anywhere now and the maintainers believe that it is "perfect".

Alternatively that D is forked.

On Friday, 6 May 2022 at 09:37:24 UTC, Ola Fosheim Grøstad wrote:

That's one reason, another reason is no long term support. If you want to maintain source code in D of any large project, you are going to run into a compiler bug and that means having to become familiar with Dmd's source code which adds a lot of overhead. If you use something like C# instead you probably won't run into a compiler bug. All I know is whenever I went to compile my project over the years I've always found a new compiler bug. D really needs a LTS build. Not having on just screams you don't care about large projects.

I also worked on vibe.d for a little bit and it had the same issue. It couldn't keep up with all the different versions of D. It might make development for D easier but it comes at the cost of the user experience. It's really just many small problems like that that just start to add up.

On Friday, 6 May 2022 at 09:37:24 UTC, Ola Fosheim Grøstad wrote:

Yes, D should investigate why the library authors don't maintain it.
It is very important for language to serve the library author well!
I hope d's officials will pay attention to it and investigate it.
D author, should really attach great importance to the excellent library author and library.