Menu
Search

Forums

Forum Index

May 24, 2022
Gravatar of DennisPosted by Dennis
in reply to Walter Bright		Reply
Dennis
Gravatar of Dennis
Posted in reply to Walter Bright


Reply
On Sunday, 22 May 2022 at 03:37:32 UTC, Walter Bright wrote:
> For another example, `noreturn` was implemented by other than me. It turns out to be incomplete. It's now in my lap to fix it.

That's the opposite of what happened. You kicked off the implementation around March 2021:
https://github.com/dlang/dmd/pulls?q=is%3Aclosed+is%3Apr+author%3Awalterbright+DIP1034

Then you abandoned it for ImportC and it got released in an incomplete state, without a preview switch.

It was actually Florian who stepped up and started fixing the issues that were pouring in because of that:

https://github.com/dlang/dmd/pulls?q=is%3Aclosed+is%3Apr+author%3Amoonlightsentinel+noreturn+

But there's still a lot more to go before DIP1034 is properly implemented.
May 24, 2022
Gravatar of FeepingCreaturePosted by FeepingCreature
in reply to burjui		Reply
FeepingCreature
Gravatar of FeepingCreature
Posted in reply to burjui


Reply

On Tuesday, 24 May 2022 at 10:22:31 UTC, burjui wrote:

>

And one of the main problems, imho, is Walter himself. He's like a child that wants to play with his favourite toys, e.g. ImportC, but hates doing homework. That's why we have many shiny new features in D, but bugs can rot their way into DMD for decades. I get that behaviour, I was like that most of my life. Judging from my own experience, he may even have untreated ADHD. He's great at programming, but sucks at leadership. And D is no longer his own toy, it's a project with many people depending on it. Whatever the problem with Walter is, it's outright irresponsible to have him as a leader.

I cannot put into words how much I disagree with this.

Rough consensus and running code! History is made by those who bother to show up. Patches welcome. The project is on Github, there is a very visible fork button on the top left. That's the same reason I violently disagree with the idea that D has too little "management." There's this idea that if we just have a really good idea, it will materialize developers out of nowhere through the sheer force of its majesty. This is not how things work, or have ever worked.

Walter works on DMD. This makes him part of an all-too-small circle of people who actually contribute to this project in any way whatsoever. All the disagreements I have with the project are the other way - I think it's too cumbersome to just jump in and contribute. I think we need a lot more people just jumping in and coding wildly ahead, and then sharing their results. An experimental branch? D3? Whatever must be changed to make that possible, I support it.

"More people need to" - Whenever you say that more people need to, you don't have a solution, you have a wish. Them needing to will not make people care, or exist. Want more features? Argue for whatever stands between existing people in the ecosystem and adding features. Want more bugfixes? Ask people why they don't fix bugs. Ask yourself why you don't fix bugs.

It is my belief that if Walter leaves D, it will die within a year or two. A project needs action. I think the codebase is in an awkwardly hard-to-maintain state for outsiders: who will fix it? Whether or not Walter does it, who else would?

One of the worst things a project can do is penalize contributions, whether through cumbersome processes, bad code, or excessive criticism. Opinions are plentiful; pull requests are scarce. It is always thus.

May 24, 2022
Gravatar of DukcPosted by Dukc
in reply to burjui		Reply
Dukc
Gravatar of Dukc
Posted in reply to burjui


Reply

On Tuesday, 24 May 2022 at 10:22:31 UTC, burjui wrote:

>

Why D is unpopular? Because people don't stay. As I can only truly speak for myself, here's the reason why I left:
https://issues.dlang.org/show_bug.cgi?id=2043

This bug is 14 years old already, and the memory-corrupting code still compiles, unless you enable DIP1000 (not a standard yet).

It's becoming one. The latest Dmd, 2.100, already prints a deprecation message about DIP1000-noncompatible code unless you explicitly add -revert=dip1000. And it's quickly becoming stable too. Only three or four releases ago, you continuosly discovered bugs if trying to seriously use DIP1000 but in my experience, there's only a fraction of that anymore.

>

There are many more papercuts like that in D: incomplete and poorly designed features, bugs that don't get fixed, the overall lack of computer science backing, resulting in what I would call a complex graph of hacks rather an elegant language.

I partially agree with that. But on the practical side, the features are often complete enough to be useful. For example, even with all it's shortcomings, I still vastly prefer -betterC to C!

And when the features are too incomplete for use, you can simply ignore them.

>

And one of the main problems, imho, is Walter himself. He's like a child that wants to play with his favourite toys, e.g. ImportC, but hates doing homework. That's why we have many shiny new features in D, but bugs can rot their way into DMD for decades. I get that behaviour, I was like that most of my life. Judging from my own experience, he may even have untreated ADHD. He's great at programming, but sucks at leadership. And D is no longer his own toy, it's a project with many people depending on it. Whatever the problem with Walter is, it's outright irresponsible to have him as a leader.

You're way too harsh. Anyone here with experience about the subject can tell that Walter has made many highly controversial decisions. But I suspect it's simply because language leadership is incredibly hard. Most people would probably not have some of the Walter's blind spots, but they would have other weaknesses and would almost certainly lack some of the exceptional qualities of Walter. Compiler knowledge, persistance and experience for example. And even if you find someone more capable, the chances of him/her being willing for the thankless job are slim.

May 24, 2022
Gravatar of Ola Fosheim GrøstadPosted by Ola Fosheim Grøstad
in reply to FeepingCreature		Reply
Ola Fosheim Grøstad
Gravatar of Ola Fosheim Grøstad
Posted in reply to FeepingCreature


Reply

On Tuesday, 24 May 2022 at 11:38:55 UTC, FeepingCreature wrote:

>

I think we need a lot more people just jumping in and coding wildly ahead, and then sharing their results. An experimental branch? D3? Whatever must be changed to make that possible, I support it.

You need a solid modular architecture to support evolutionary development. There is enough CPU power to take the overhead in 2022. Designing architecture is hard on-paper work, not something you evolve though. So that is where one should start.

If you want merging to be easy then you need to select features that are independent in each iteration. People working on random things make the process harder and more brittle, but a solid architecture and AST macros can help. Depends, only one type system feature at a time for instance...

Maybe Neat and SDC could be joined and form a foundation?

Think O(N) and modularity and forget all other performance metrics until you hit v1.0... Designing for flexibility is quite challenging. GC is ok etc...

May 24, 2022
Gravatar of FeepingCreaturePosted by FeepingCreature
in reply to Ola Fosheim Grøstad		Reply
FeepingCreature
Gravatar of FeepingCreature
Posted in reply to Ola Fosheim Grøstad


Reply

On Tuesday, 24 May 2022 at 13:09:54 UTC, Ola Fosheim Grøstad wrote:

>

On Tuesday, 24 May 2022 at 11:38:55 UTC, FeepingCreature wrote:

>

I think we need a lot more people just jumping in and coding wildly ahead, and then sharing their results. An experimental branch? D3? Whatever must be changed to make that possible, I support it.

Maybe Neat and SDC could be joined and form a foundation?

(Brief sidenote: Neat is a totally different compiler and language, it only steals some syntax from D. It's a project that is motivated by my experience with D, but it's not a D variant. It's doing its own thing, language-wise. Not to mention that it's far pre-1.0 in terms of D-equivalent features.)

>

You need a solid modular architecture to support evolutionary development. There is enough CPU power to take the overhead in 2022. Designing architecture is hard on-paper work, not something you evolve though. So that is where one should start.

Fully agreed, but don't underestimate how magical DMD's performance is. I wish neat's compiler was as speedy.

May 24, 2022
Gravatar of deadalnixPosted by deadalnix
in reply to Walter Bright		Reply
deadalnix
Gravatar of deadalnix
Posted in reply to Walter Bright


Reply
On Tuesday, 24 May 2022 at 05:39:50 UTC, Walter Bright wrote:
> On 5/22/2022 6:31 AM, deadalnix wrote:
>> https://issues.dlang.org/show_bug.cgi?id=1983
>
> It's been fixed already. Just nobody closed it.

No.

```d
struct S {
    void delegate() dg;
}

void main() {
    int x = 42;
    immutable S s = { dg: () { x++; } };
    s.dg();

    import std.stdio;
    writeln(x);
}
```

This still compiles and run and mutates a variable through an immutable pointer. This variable could be shared too because immutable is safe to share.
May 24, 2022
Gravatar of zjhPosted by zjh
in reply to FeepingCreature		Reply
zjh
Gravatar of zjh
Posted in reply to FeepingCreature


Reply

On Tuesday, 24 May 2022 at 11:38:55 UTC, FeepingCreature wrote:

>

A project needs action.

It's actually very simple,Just prioritize coding tasks.
We should organize the community.
D community should be organized, even if it is loose, it is better than unorganized.
The problem with the d community is that it is too loose.

May 24, 2022
Gravatar of deadalnixPosted by deadalnix
in reply to Ola Fosheim Grøstad		Reply
deadalnix
Gravatar of deadalnix
Posted in reply to Ola Fosheim Grøstad


Reply

On Tuesday, 24 May 2022 at 05:22:48 UTC, Ola Fosheim Grøstad wrote:

>

Adding more features is probably not an improvement overall.

Indeed, the breakage is also estimated in a very bizarre way (at the end of the day, it's all about cost of the breakage vs benefit of the change).

The worse offender as far as I can tell is random feature added. They break all kind of tooling, every time.

May 24, 2022
Gravatar of mee6Posted by mee6
in reply to FeepingCreature		Reply
mee6
Gravatar of mee6
Posted in reply to FeepingCreature


Reply

On Tuesday, 24 May 2022 at 11:38:55 UTC, FeepingCreature wrote:

>

Ask people why they don't fix bugs. Ask yourself why you don't fix bugs.

I don't get paid to. It's also an awful developer experience. There's no readme that explains how to build it, it's better now with the build.d script but until recently you just had to wing it. Still do for phobos and druntime. Also a lot of the time pull requests just stay open, for various reasons including requesting Walters approval which he'll never look at.

It takes a lot of time to get up to speed to fix bugs in DMD. I don't know if the people in the d foundation are getting paid but I assume they are. If you want more people in the community to fix bugs, you have.to pay them. It takes skill to do that. Otherwise people want to work on their own projects and not spend hours fixing a bug they hit in a tool they are using for their project, then to only have your pull request closed cause it got stale waiting for someone to look at it.

May 24, 2022
Gravatar of zjhPosted by zjh
in reply to zjh		Reply
zjh
Gravatar of zjh
Posted in reply to zjh


Reply

On Tuesday, 24 May 2022 at 13:21:53 UTC, zjh wrote:

>

We should organize the community.
D community should be organized,

what D need is organization, and to make effective use of our spare time .
Moreover, consensus should be strengthened.
For the things that have been discussed, just give a link. You don't have to discuss the same things repeatedly. It's too annoying and a waste of time.

« First   ‹ Prev
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 …
Next ›   Last »