June 10, 2022

On Friday, 10 June 2022 at 15:24:08 UTC, Paul Backus wrote:

>

On Friday, 10 June 2022 at 14:24:06 UTC, zjh wrote:

>

On Friday, 10 June 2022 at 14:14:46 UTC, Paul Backus wrote:

>

No, it's because there's too much shared mutable state, and not enough immutable objects and pure functions.

Can it be improved by splitting large source files into small files?
I think should refactor 'dmd' aggressively.

The size of the source files is not the problem.

Wouldn't hurt though.

June 12, 2022

On Friday, 10 June 2022 at 01:08:02 UTC, mesni wrote:

>

D has AA and arrays built into the language and runtime. But why are sumtype, arrays/smart pointers using custom allocators, nullable, tuple at the expense of std? Everything listed in this article https://dlang.org/articles/builtin.html applies to them. I think this can be done as something like an optional extension in the compiler.

That's one of the reason i'm more and more using Zig these days

I don't have to import some random bullshit to have tagged union with pattern matching

They'll also have a language server built into the compiler as well as binary patching (meanwhile nobody merge PRs in DCD, and it ends up being a rotten software that is CRUCIAL to D adoption)

D is a superior language, BY FAR, but these little things are what makes the difference when you just want to appreciate a language without people telling you to import std.sumtype to have tagged union

Two different mindset, at the end, i pick what's make me the less annoyed in the long run, and that's zig's tagged union

Really we need to wake up and make D better

C# will have NativeAOT in the next major version btw!

Our competitive features are becoming the norm, and we are failing behind in many other crucial areas

June 12, 2022

On Sunday, 12 June 2022 at 13:40:16 UTC, ryuukk_ wrote:

>

Our competitive features are becoming the norm, and we are failing behind in many other crucial areas

You're right, d' need depends on the strength of the organization. DMD needs radical refactoring.
The source code is too bad. Divide large files into small files and do class encapsulation!

June 12, 2022

On Sunday, 12 June 2022 at 14:29:41 UTC, zjh wrote:

>

DMD needs radical refactoring.
The source code is too bad. Divide large files into small files and do class encapsulation!

D should stop 'D2', develop 'D3' and radically refactor 'DMD' for 'D3'.

What should we do if even experts can not 'correctly and completely' realize new features?

June 12, 2022

On Sunday, 12 June 2022 at 14:34:23 UTC, zjh wrote:

>

What should we do if even experts can not 'correctly and completely' realize new features?

The reason why there are few contributors is that the code can not realize class level encapsulation!
Without encapsulation, the code is a mess.

A bunch of thousands of lines of code files, how to contribute?
Why not split it into dozens of small files into hundreds lines files?

June 12, 2022

On Sunday, 12 June 2022 at 14:46:29 UTC, zjh wrote:

>

Without encapsulation, the code is a mess.

A bunch of thousands of lines of code files, how to contribute?
Why not split it into dozens of small files into hundreds lines files?

We all know the story of 'VIM' and 'Nvim'. What 'd' needs is 'radical' change, and 'DMD' needs to be completely reconstructed!
At this time, it makes sense to completely refactor .
Keep 'D2' for maintenance version only!
Only through 'thorough' reconstruction can activat people's interest in participating in 'DMD'!

June 12, 2022

On Sunday, 12 June 2022 at 15:05:55 UTC, zjh wrote:

>

We all know the story of 'VIM' and 'Nvim'. What 'd' needs is 'radical' change, and 'DMD' needs to be completely reconstructed!
At this time, it makes sense to completely refactor .
Keep 'D2' for maintenance version only!
Only through 'thorough' reconstruction can activat people's interest in participating in 'DMD'!

C++ was revived through the radical 'c++11'
Python has been revived through the radical 'PY3'
D also needs 'D3' to revive!
The earlier the radical refactoring dmd, the better.

June 12, 2022

On Sunday, 12 June 2022 at 14:46:29 UTC, zjh wrote:

>

On Sunday, 12 June 2022 at 14:34:23 UTC, zjh wrote:

>

What should we do if even experts can not 'correctly and completely' realize new features?

The reason why there are few contributors is that the code can not realize class level encapsulation!
Without encapsulation, the code is a mess.

A bunch of thousands of lines of code files, how to contribute?
Why not split it into dozens of small files into hundreds lines files?

"class level encapsulation" is absolutely unnecessary. don't put your class into module scope if you don't want it's internals exposed to the module in the first place.
Also it's not the problem with dmd's code base. dmd lacks documentation, and has mutablility all over the place.
Splitting files into smaller modules wouldn't hurt though

June 12, 2022

On Sunday, 12 June 2022 at 14:34:23 UTC, zjh wrote:

>

D should stop 'D2', develop 'D3' and radically refactor 'DMD' for 'D3'.

People have to agree on what D3 would be like, meaning: write a spec that they agree on.

June 12, 2022
On Sunday, 12 June 2022 at 17:29:27 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 12 June 2022 at 14:34:23 UTC, zjh wrote:
>> D should stop `'D2'`, develop `'D3'` and radically refactor `'DMD'` for `'D3'`.
>
> People have to agree on what D3 would be like, meaning: write a spec that they agree on.

No. D3 will be a fork... too many people stuck in their ways at the moment :-(