www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Dlangs inconsistent decision making and ai

reply monkyyy <crazymonkyyy gmail.com> writes:
D's political failures waste an extreme amount of effort and has 
been an on going complaint for at least 2 decades, some possible 
contributors may not have been born before the first rage quit 
from dlang. I cant fathom how yall thought the half completed 
wasm runtime should've been allowed to rot.

This is incredibly stupid and Ive never seen the core team 
acknowledge the problem or empathize with the outsiders.

Wearing my politics on my sleeve, I believe the blunt force 
solution to communication problems is clear ownership; when 
Britain was a 2 month round trip by boat from america requiring 
paperwork to physically travel by boat to get signed off was 
retarded; the red coats may have been able to keep their empire 
if they invested in fax machines in time. When decision making 
breaks down, you move the decision making to be more local.

If upstream is adopting ai, may as well use it. While my 
historical suggestion to spread ownership around by shipping 2nd 
party libs appearly was so beyond the pale to be considered for a 
even moment. It seems to me you can get ownership-like effects 
with ai.

Instead of a fucking half-baked "lets say no by default" "you 
MUST describe your problem to half deaf ears, with possibly weeks 
of delay of communication" polices; construct personality 
profiles on representatives to review pr's and assign ownership 
by file with %'s.

Consider std.json, theres a file json.d, everyone hates it I 
wouldnt even want "ownership", the natural place to assign 
ownership is on ceo's of any of the corps that have made the 
unfortunate misinvestment to depend on it. So a major share of 
this json.d like 30% goes to grumpy ceo, the grumpy ceo 
"personality" file is loaded into the pr reviewing ai. Presumably 
the personality file will contain lines like "has project foo" 
"cares mostly about preventing breaking changes" maybe the ai can 
rub 2 brain cells together and download that project "foo" and 
check for breaking changes with the actual compiler *within 
minutes*.

So, construct the social graph, assign ownership of files to most 
important parties, set up a pr reviewing bot that at least 
attempts to find the relevant opinions quickly. It only has to be 
better then walter not reading your pr and asking for "whats the 
usecase" even when its stated 3 times in the thread.
Aug 29
next sibling parent reply Kapendev <alexandroskapretsos gmail.com> writes:
On Saturday, 29 August 2026 at 20:54:06 UTC, monkyyy wrote:

 D's political failures waste an extreme amount of effort and 
 has been an on going complaint for at least 2 decades, some 
 possible contributors may not have been born before the first 
 rage quit from dlang. I cant fathom how yall thought the half 
 completed wasm runtime should've been allowed to rot.

 This is incredibly stupid and Ive never seen the core team 
 acknowledge the problem or empathize with the outsiders.

 Wearing my politics on my sleeve, I believe the blunt force 
 solution to communication problems is clear ownership; when 
 Britain was a 2 month round trip by boat from america requiring 
 paperwork to physically travel by boat to get signed off was 
 retarded; the red coats may have been able to keep their empire 
 if they invested in fax machines in time. When decision making 
 breaks down, you move the decision making to be more local.

 If upstream is adopting ai, may as well use it. While my 
 historical suggestion to spread ownership around by shipping 
 2nd party libs appearly was so beyond the pale to be considered 
 for a even moment. It seems to me you can get ownership-like 
 effects with ai.

 Instead of a fucking half-baked "lets say no by default" "you 
 MUST describe your problem to half deaf ears, with possibly 
 weeks of delay of communication" polices; construct personality 
 profiles on representatives to review pr's and assign ownership 
 by file with %'s.


I had an idea like that recently on the D Discord server.
You could make a friend list for every D module.
A friend is allowed to modify anything, even a private field, 
while a simple acquaintance is forced to follow the rules set by 
the master and his friends.

Example:

```d
module std.json;
pragma(friends, "master:serg:user1234");
```

This idea can be extended to include things like ownership of a 
file.
For example, only friends are allowed to import a module.
Friends can be defined via CLI arguments.
An optional password could be passed for enforcing extra module 
safety.
That one actually might be a great step towards "Spatial Code 
Safety" as some people call it online.


 Consider std.json, theres a file json.d, everyone hates it I 
 wouldnt even want "ownership", the natural place to assign 
 ownership is on ceo's of any of the corps that have made the 
 unfortunate misinvestment to depend on it.


You will get ownership and you will be happy.


 new code in the std


What we want is librarymaxxing and dependecymaxxing.
STDs are bad. Spreading them is even worse. Search "STD" right 
now on Google or DuckDuckGo (or ask an AI), and tell me if it's 
really good or not. I can wait.
Aug 29
parent reply ABrightLight <example example.com> writes:
On Sunday, 30 August 2026 at 06:20:12 UTC, Kapendev wrote:

 I had an idea like that recently on the D Discord server.
 You could make a friend list for every D module.
 A friend is allowed to modify anything, even a private field, 
 while a simple acquaintance is forced to follow the rules set 
 by the master and his friends.

 Example:

 ```d
 module std.json;
 pragma(friends, "master:serg:user1234");
 ```


I highly recommend staying away from C++'s friend design. It will 
needlessly complicate the language.
Sep 01
next sibling parent "H. S. Teoh" <hsteoh qfbox.info> writes:
On Tue, Sep 01, 2026 at 02:09:11PM +0000, ABrightLight via Digitalmars-d wrote:

 On Sunday, 30 August 2026 at 06:20:12 UTC, Kapendev wrote:

 I had an idea like that recently on the D Discord server.
 You could make a friend list for every D module.
 A friend is allowed to modify anything, even a private field, while
 a simple acquaintance is forced to follow the rules set by the
 master and his friends.
 
 Example:
 
 ```d
 module std.json;
 pragma(friends, "master:serg:user1234");
 ```


 
 I highly recommend staying away from C++'s friend design. It will
 needlessly complicate the language.


+1, yeah please don't ruin D by reintroducing C++'s "friend" that we
paid a high price to get away from.


T

-- 
Why waste time reinventing the wheel, when you could be reinventing the engine?
-- Damian Conway
Sep 01
prev sibling parent Basile B. <b2.temp gmx.com> writes:
On Tuesday, 1 September 2026 at 14:09:11 UTC, ABrightLight wrote:

 On Sunday, 30 August 2026 at 06:20:12 UTC, Kapendev wrote:

 I had an idea like that recently on the D Discord server.
 You could make a friend list for every D module.
 A friend is allowed to modify anything, even a private field, 
 while a simple acquaintance is forced to follow the rules set 
 by the master and his friends.

 Example:

 ```d
 module std.json;
 pragma(friends, "master:serg:user1234");
 ```


 I highly recommend staying away from C++'s friend design. It 
 will needlessly complicate the language.


In the past I had eventually imagined that `__traits()` could be 
a god mode, with a kind of "omnipotence". You can get everything 
you want but you can also choose to respect the visibility (since 
`__traits()` also permits to get this information). The rationale 
is that since finally code based on`__traits()`, i.e meta-prog, 
is usually very heavy to write you get get in exchange the 
omnipotence.
Sep 01
prev sibling parent GB <gb542 gmail.com> writes:
On Saturday, 29 August 2026 at 20:54:06 UTC, monkyyy wrote:

 [...]


Interestingly, 'clear ownership' is a core component of CobaltC.

https://strawberry9.github.io/the-wrong-memory/Appendix_06.html

So programming languages have already learnt the consequences of 
not having clear ownership.
Aug 31