[DenisM]

>to a language which has already surpassed its complexity budget

I've been thinking that way for many years now, but clearly I've been wrong. Perhaps C++ is the one language to which the issue of excess complexity does not apply.

[selfmodruntime]

In essence, a standard committee thinks like bureaucrats. They have little to no incentive to get rid of cruft and only piling on new stuff is rewarded.

[WalterBright]

In D, we are implementing editions so features that didn't prove effective can be removed.

[bluGill]

I don't know what you mean by effective - I can come up with several different/conflicting definitions in this context.

I think what you meant to say is popular. If a feature is popular it doesn't matter how bad it turns out in hindsight: you can't remove it without breaking too much code (you can slowly deprecate it over time, I'm not sure how you handle deprecation in D, so perhaps that is what editions give you). However if a great feature turns out not to be used you can remove it (presumably to replace it with a better version that you hope people will use this time, possibly reusing the old syntax in a slightly incompatible way)

[selfmodruntime]

I am sadly not in the position to use D at work, but I appreciate your work!

[poppadom1982]

Yeah dude but you've really marketed D poorly. I remember looking at D what must be 15 years back or so? And I loved the language and was blown away by its beauty and cool features. But having no FOSS compiler and the looming threat of someone claiming a patent (back then it was unclear that Mono/C# was "legal" and even Java hung in the balance) was too scary for me to touch it.

Now I'm old and I believe D has missed its opportunity. Kinda sad.

[WalterBright]

D is 100% open source. The gnu D compiler and the LLVM D compiler were always 100% open source.

[WalterBright]

I don't recall anyone making a patent claim.

[poppadom1982]

Open source and free software isn't the same thing. Nobody made a claim on Java either, until someone did. I just distinctly remember explicitly not exploring D for that reason. Also this way way before LLVM and I also don't think GNU had a D compiler back then. There was only the (and I really believe it was closed source) Digital Mars compiler.

[riffraff]

The scheme folks managed to shed complexity between R6RS and R7RS, I believe.

So perhaps I think the issue is not committees per se, but how the committees are put together and what are the driving values.

[muvlon]

Notably they didn't fully shed it, they compartmentalized it. They proposed to split the standard into two parts: r7rs-small, the more minimal subset closer in spirit to r5rs and missing a lot of stuff from r6rs, and r7rs-large, which would contain all of r6rs plus everyone's wildest feature dreams as well as the kitchen sink.

It worked remarkably well. r7rs-small was done in 2013 and is enjoyed by many. The large variant is still not done and may never be done. That's no problem though, the important point was that it created a place to point people with ideas to instead of outright telling them "no".