Menu
Search

Forums

Forum Index

May 24, 2022
Gravatar of forkitPosted by forkit
in reply to Walter Bright		Reply
forkit
Gravatar of forkit
Posted in reply to Walter Bright


Reply
On Tuesday, 24 May 2022 at 04:58:00 UTC, Walter Bright wrote:
> ...
> ....
> My plan after ImportC has reached a certain point is to go through every issue on bugzilla marked with the "safe" keyword. (Of course, anyone else can, too.)
> ...
> ....

This is great news! We all really need your talent re-focused into that area.

And... being able to further promote D's '@safe', will likely go a long way (than ImportC perhaps) in making D more.. umm... 'popular'.
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 05:22:48 UTC, Ola Fosheim Grøstad wrote:

>

On Tuesday, 24 May 2022 at 02:04:34 UTC, Basile B. wrote:

>

You finally ends up with testimonials from experts but in the end you still dont really know why mr rookie gave D up.

Overall the signal from beginners that did not give up early appears to be IDE and libraries. From experienced beginners the signal is inconsistencies and unusual choices. From nonhardcore the signal is lack of stability. From hardcore the signal is incompleteness.

Actually, I want to jump on this, because I think it's really important, and it's a core argument from my perspective for why D should have macros.

Note: Speaking from an unabashed late-intermediate perspective.

Most languages have this sort of pipeline:

[beginners] -> [experienced beginners] -> [intermediates] -> [hardcore]

[code for own use] -> [code libraries] -> [utility libraries] -> [language improvements]

It sometimes feels like D has this pipeline:

[code for own use] -> [libraries] -> [clever metaprogramming libraries] -> [I'll make my own language!]

And that's an issue! Because people tend to fall off the end of the development pipeline right when they're the most useful. There's what, five languages that started from D? Amber, Volt, Symmetry's fork (?), my own Neat... It's gotten less with D2, but I feel the combination of limitations at the high end of utility libraries and the lack of truly deep language expansion on the one hand, the slow, somewhat opaque, and arguably criticism-driven DIP process on the other, and the, charitably, somewhat impenetrable DMD codebase on the third, risks alienating people when they'd be the most useful to the project.

With something like C++ I ironically think that's less of an issue because there's "more to learn" at the high end. I think people rarely feel like they've plateaued in how far they can take the language, because they get so stuck in their awkward templates that even gradual improvements feel like victories. Or with simpler languages, like Node, it's easier to make a case that what's there is complete, from a language perspective. But because D is both powerful and comprehensible, you reach "the end", understand it, and you see that there's nowhere else to go except either braving the feature proposal process and the hostility of half the forum, or go elsewhere.

To be clear, losing people at any stage of the pipeline is bad for a language. But I think losing people at the end has unique costs in terms of proselytizing and advancement.

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 06:17:38 UTC, FeepingCreature wrote:

>

Actually, I want to jump on this, because I think it's really important, and it's a core argument from my perspective for why D should have macros.

Are you talking of AST macros?

The reason I think D should do proper expansion of C macros is just that it makes it possible to view it as a high level alternative to C, so you get some kind of marketable focus into the project. But there are some randomish anti-C design aspects that works against it.

>

And that's an issue! Because people tend to fall off the end of the development pipeline

Yes, something like SDC is needed, but it is difficult to believe in when D keeps moving in an unpredictable manner. Does SDC need importC?

>

There's what, five languages that started from D?

Probably more, private forks... but it is easy to predict that SDC will be forced in a similar direction by first going for a subset and take a different direction.

>

With something like C++ I ironically think that's less of an issue because there's "more to learn" at the high end.

C++ has more focus by not being suitable for higher level coding. Too many D users want only one language for everything and that leads to neverending feature creep instead of polishing a more narrow reportoire.

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 07:15:15 UTC, Ola Fosheim Grøstad wrote:

>

On Tuesday, 24 May 2022 at 06:17:38 UTC, FeepingCreature wrote:

>

Actually, I want to jump on this, because I think it's really important, and it's a core argument from my perspective for why D should have macros.

Are you talking of AST macros?

Yeah, some combination of CTFE and DMDFE-as-a-library to allow CTFE functions to operate on (some abstraction over) code trees directly. The idea is that something like format strings could be offered as a library before it even entered the DIP process. That might also allow pulling a bunch of functionality out of the core language.

May 24, 2022
Gravatar of Timon GehrPosted by Timon Gehr
in reply to Walter Bright		Reply
Timon Gehr
Gravatar of Timon Gehr
Posted in reply to Walter Bright


Reply
On 24.05.22 07:39, 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.

The original example no longer compiles, there are others in that thread. It has not been fixed!
May 24, 2022
Gravatar of Timon GehrPosted by Timon Gehr
in reply to Walter Bright		Reply
Timon Gehr
Gravatar of Timon Gehr
Posted in reply to Walter Bright


Reply
On 24.05.22 07:31, Walter Bright wrote:
> 
>> https://issues.dlang.org/show_bug.cgi?id=2043
> 
> We have better tools to deal with 2043 today. Note that dgList exceeds the lifetime of b, and should fail to compile for that reason.
> 
> Let's try it (adding import and @safe and updating the code to D2):
> ----
> import std.stdio;
> 
> @safe:
> 
> void delegate()[] dgList;
> 
> void test() {
> 
>          foreach(int i; [1, 2, 3]) {
>                  int b = 2;
>                  dgList ~= { writeln(b); };
>                  writeln(&b); // b will be the *same* on each iteration
>          }
> }
> ----
> 
>  > dmd test.c -preview=dip1000
> test.d(13): Error: reference to local variable `b` assigned to non-scope parameter `_param_0`
> 
> Looks like we can close it now!

No. The correct behavior when a delegate literal outlives captured variables is to allocate a closure. This case is not an exception...
May 24, 2022
Gravatar of FeepingCreaturePosted by FeepingCreature
in reply to Timon Gehr		Reply
FeepingCreature
Gravatar of FeepingCreature
Posted in reply to Timon Gehr


Reply

On Tuesday, 24 May 2022 at 07:45:38 UTC, Timon Gehr wrote:

>

On 24.05.22 07:31, Walter Bright wrote:

> >

https://issues.dlang.org/show_bug.cgi?id=2043

We have better tools to deal with 2043 today. Note that dgList exceeds the lifetime of b, and should fail to compile for that reason.

Let's try it (adding import and @safe and updating the code to D2):

import std.stdio;

@safe:

void delegate()[] dgList;

void test() {

        foreach(int i; [1, 2, 3]) {
                int b = 2;
                dgList ~= { writeln(b); };
                writeln(&b); // b will be the same on each iteration
        }
}

>

dmd test.c -preview=dip1000
test.d(13): Error: reference to local variable b assigned to non-scope parameter _param_0

Looks like we can close it now!

No. The correct behavior when a delegate literal outlives captured variables is to allocate a closure. This case is not an exception...

This is a bit of a controversial topic. Personally I agree that there should be a closure allocated every loop pass, but every other language allocates them for the whole stackframe, so... But then handling b is awkward, because the way that compilers usually square that circle is that they allocate a separate spot in the stackframe per variable declaration, so the loop variable only gets one distinct declaration. And it's hard otherwise, because if you allocate a separate frame every loop, then they can't reference each others' variables. Some languages solve this by making lambdas unable to write scope variables, but then obviously they're less useful. Anyway, so in this case the delegate can't help outlive b even if it's closure allocated.

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 06:02:23 UTC, FeepingCreature wrote:

>
  • Every bugfix has to be rebased three times

No, you freeze nextgen 1 year before release and focus on polish.

Different people on experimental and nextgen. Experimental is for new features (more than one branch), nextgen is for integration.

It should not be much different from what you have with a solid process.

>

Honestly, I don't understand this. We get maybe one or two bugs from DMD updates every half-a-year. What's the issues that cause so much upgrade costs?

You are hardcore. Many D users take breaks, then come back and ask for a stable branch. If you want breaking changes you need a buffer.

There are virtually no breaking changes in popular languages people are used to: c++, go, python, javascript etc

May 24, 2022
Gravatar of IGotD-Posted by IGotD-
in reply to Walter Bright		Reply
IGotD-
Gravatar of IGotD-
Posted in reply to Walter Bright


Reply
On Sunday, 22 May 2022 at 03:37:32 UTC, Walter Bright wrote:
>
> I'm sorry about giving that impression, but I literally cannot remotely do what everyone asks me to. I'm not Microsoft with 10,000 engineers at my command. And your request *did* get eventually implemented.
>

You could have those 10000 engineers at your disposal but they wouldn't even know what to do. They would just sit idling or play computer games their entire days. In order make people move you need to have a clear vision, write architecture documents, write work packages and so forth which you or no one in the D management does.

Right now people in the D project don't even know what to do or implement. Should D have co-routines or should async/await be implemented? Then we need a document that explains to everybody what needs to be implemented so people can go pick a certain work package they want to implement.

The D project consist mostly of coders who just start right away, which was obvious with your importC which came out of nowhere. Now, I don't demand that everybody should be full seasoned managers but the D project certainly lacks these types of people. Also people who perhaps want to step away from coding and write architecture/design documents would help.
May 24, 2022
Gravatar of burjuiPosted by burjui
in reply to deadalnix		Reply
burjui
Gravatar of burjui
Posted in reply to deadalnix


Reply

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

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.

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.

Also, D definitely need a whole lot more of:

  1. Compiler experts, because the current pace of progress is so incredibly slow, that eventually even the most hardcore fans will lose temper, like I did, and leave the project. By progress I mean not only adding features but fixing bugs too.
  2. Computer scientists. You know, type theory and all the related stuff is really important in designing a language. There is a whole spectrum of complexity and usability, from Forth and Lisp to C++ and D. Both ends of the spectrum suck. There has to be some middle ground, where you have a sufficiently powerful, yet relatively simple language (relative to C++). For that, you need science. Slapping a yet another feature on top with scotch tape is not going to work in the long run.
« First   ‹ Prev
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 …
Next ›   Last »