May 06, 2022
On Thursday, 5 May 2022 at 23:06:26 UTC, Walter Bright wrote:
> On 5/3/2022 10:54 PM, Max Samukha wrote:
>> The important part is that Nemerle can execute functions at compile time - whether it's done via interpretation or compilation is not relevant to the argument. D could as well compile CTFE into native code or IL (as in newCTFE) from the start.
>
> That's pedantically true. But I can't seem to explain the difference to you. D doesn't have a compiler in the runtime. Having a compiler in the runtime means that you can dynamically create code and compile it at runtime.
>
> It's a *fundamental* difference.
>
> If there is no difference (after all, all of them are Turing machines, no difference at all!), and CTFE is popular and well known, did
>
>     ZERO
>
> of the native compilers do it? Why didn't it appear on feature wish lists? Why wasn't it in C/C++/Pascal/Fortran/Module2/Ada/Algol compilers?
>

It was in the Nim(rod) compiler which is a Modula 3 derivate quite early in the project's lifetime, maybe as early as 2004, maybe later, I don't remember. And maybe D had it earlier. However:

1. I'm quite sure I didn't copy it from D. Because:
2. Nim actually **needs** it because otherwise its AST macro system simply cannot work.

May 06, 2022

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

>

For example, I can have a tool which calculates Pi number with high precision. Then I bundle this tool as a part of the project and simply use the computed constant in the source code. This extra tool is very visible in the project structure and there's nothing obscure about it. But with the CTFE approach, somebody may be tempted to do the expensive Pi constant computation every time at the compilation time. And this may be hidden somewhere deep in the source code in a much less visible way. Looks like such feature makes it too easy to shoot yourself in the foot.

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.

May 06, 2022
On Friday, 6 May 2022 at 06:57:52 UTC, Siarhei Siamashka wrote:
> On Friday, 6 May 2022 at 06:18:08 UTC, Patrick Schluter wrote:
>> That's the point. It reduces build complexity in a disruptive way.
>
> My point is that CTFE actually increases the complexity and moves it somewhere else in a somewhat obscure way. It's one of the zillions of extra features that make the language spec bloated and difficult to learn.

It's exactly the contrary of this.

Doing thing at compile time with templates implies something new and difficult to learn (see C++). Doing things at compile time with CTFE don't add anything new to learn, you write code as always.



May 06, 2022

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

>

Doing thing at compile time with templates implies something new and difficult to learn (see C++). Doing things at compile time with CTFE don't add anything new to learn, you write code as always.

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.

May 06, 2022

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

>

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.

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!

May 06, 2022

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

>

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

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.

>

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

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…

May 06, 2022

On Friday, 6 May 2022 at 09:37:24 UTC, Ola Fosheim Grøstad 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.

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.

May 06, 2022

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

>

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

>

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

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.

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.

May 06, 2022

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

>

One key issue that has been mentioned in this thread is that people leave because of inconsistencies in the language.

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.

May 06, 2022
On Friday, 6 May 2022 at 09:47:22 UTC, IGotD- wrote:
> On Friday, 6 May 2022 at 09:37:24 UTC, Ola Fosheim Grøstad 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.
>
> 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.

the problem with forks, is finding competent compiler developers.. and there ain't that many of them.

then you need a competent team to mangage the fork...and there ain't too many of them either...

it forkin aint' easy...to fork.

btw. the premise of the question posed ( a long...long..long time ago..)
.. is flawed and kinda meaningless.

the question should have been => 'Why is D not widely used'.