www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The ensloppification of D is a grave mistake

reply solidstate1991 <laszloszeremi outlook.com> writes:
Setting aside artists' concerns about genAI automating away part 
of the human experience, setting aside environmental issues such 
as water and electricity usage, setting aside social issues such 
as the accessibility of creating propaganda in large amount, even 
setting aside issues from code quality, which all will drive away 
potential users from the D ecosystem, there's still one issue: 
licensing.

GenAI models has been trained on the internet. They tried to vet 
it, yet again and again things are slipping through the cracks. 
This means code that licensed GPL is in the training material, 
and sometimes it can resemble the original code very closely, see 
the FreeBSD exFAT driver, that was a bit less stable regeneration 
of the Linux exFAT driver hacked onto FreeBSD. Even worse is, 
that on the internet, we have both "source code viewable" type 
solutions, and source code that has been acquired through dubious 
means, to be then shared illegally without the consent of the 
original writers.

On one hand, this creates a legal minefield for us, possibly 
forcing us into a lawsuit, or to relicense Phobos, ending with 
relicensing every later D applications. On the other hand, it can 
help to erode the social contract around open source.

Even if we get over these issues, there's the problem of code 
quality. Sometimes vibe coded applications pass basic safety 
checks, but then real-life tests prove those otherwise, and the 
code is overinflated with extra lines and extra unnecessary 
tricks. Sure, it might amaze the intended audience, business 
people who either invest or were told they'd be the next 
generation of programmers, but in the long-run, it will just 
result with extra lines. GenAI code also led to an epidemic of 
"library slop": libraries created just because someone could, not 
because of someone needed them. Every time I thought of making a 
new library, I checked what's available rather than diving deep 
into making them myself. Now the new standard is making 
everything yourself just because it's more trendy that way.

I therefore demand to stop adopting LLM usage for the development 
of the standard library at least, but I would be extra thankful 
if the D Language Foundation could do a 180 degree turn on LLM 
adoption. As a heads up on that front: the Rust community tries 
its best to hide the language's adoption of core functional 
programming features as defaults, and now they try to market them 
as "common sense features" to distance themselves from the issues 
the functional programming paradigm might cause in some 
instances, such as in game development, no matter how much toxic 
positivity does the Rust community spread about the language and 
Bevy. At this moment, it would be easy to do so.

I understand it. I born in the nineties, and I had some family 
members who got afraid I might get addicted to this fancy new toy 
called "computer" to the point that after a while, I won't be 
satisfied by GTA or Doom, but by getting a machine gun from the 
black market, then shoot up my school. Others were concerned, 
that corporations might drop computers, because "they like to 
crash constantly". Yet others were concerned that I might be 
secretly a sports star, and the computer is the reason why I 
don't give it a real try. But I also remember the countless 
technologies that did not get adapted by the end, at least to the 
degree some people wanted. And there are also technologies being 
trashed solely because something fancier-looking exists, such as 
physical media.

I don't want to leave, but things might force me to do so. Every 
other alternative, thanks to the success of Rust, is OCaml with 
curly braces for scope delimiting. D even lets me to have two 
kinds of memory management at once, while all other languages try 
to limit themselves to a few select tools, and force their users 
to follow "best practices" like functional programming. I also 
fear, that this will on-par with the disaster of D1 vs. D2 and 
Phobos vs. Tango.

signed: László Szerémi / ShapeshiftingLizard / ZILtoid1991 ( 
ziltoid1991 proton.me )
Jul 03
next sibling parent reply Adam Wilson <flyboynw gmail.com> writes:
On Friday, 3 July 2026 at 10:55:19 UTC, solidstate1991 wrote:

 On one hand, this creates a legal minefield for us, possibly 
 forcing us into a lawsuit, or to relicense Phobos, ending with 
 relicensing every later D applications. On the other hand, it 
 can help to erode the social contract around open source.


IANAL, but yes, there is a possibility of a legal issues ahead 
for LLM's. However, I would ask, do you not think that some of 
the best legal minds in the world have spent untold numbers of 
hours asking all these questions already? With the benefit of 
being actual legal scholars?

I also think you seriously underestimate how conservative the 
legal departments at tech corps tend to be. If I may share a 
story from my time at Microsoft:

I wanted to add an OSS library to our project. It was one of the 
licenses Microsoft allows, solved a huge problem for my team, and 
most importantly was already used extensively inside Microsoft on 
other teams. I needed my bosses approval, his bosses approval, 
and once I had those, I had to spend a day completing 
paperwork... For a library that Microsoft already used internally.

That is how risk-averse the average corporate legal department is.

Do you really think a legal department would allow a 
multi-trillion dollar company to blindly run into the biggest 
potential legal minefield in decades without first having at 
least spent a few man-decades of time figuring out all the ways 
to NOT step on a mine?

There is one potential risk vector for Phobos I can see, and that 
is someone being sued for using Phobos in their product. This is 
possible, however, there are no such lawsuits currently in 
progress. All LLM related lawsuits at the moment are targeted at 
the tools themselves. Thus the risk remains entirely theoretical 
at present.

I am not saying that their are **NO** risks, but what I am saying 
that you are most likely significantly over-estimating the legal 
risk here.

Again, IANAL.

I would note that the biggest OSS organization in the world by 
number of active devs, the Linux Foundation, is not only actively 
incorporating large volumes of LLM generated code into the Linux 
kernel, they are considering [removing all LLM attribution 
requirements](https://www.phoronix.com/news/Linux-AI-Attribution-Again),
because realistically, nobody actually cares how the code was created, only
that the code meets their quality metrics. If the LF is legally unconcerned
then I see no reason why an org as small and penniless as D should be more
concerned.


 I therefore demand to stop adopting LLM usage for the 
 development of the standard library at least, but I would be 
 extra thankful if the D Language Foundation could do a 180 
 degree turn on LLM adoption.


I am going to be blunt. There is a sort of naive hauteur required 
to make such a demand.

Your post approaches this topic as though, we the community, must 
immediately acquiesce to your demand without any further 
consideration of the topic. As best I can tell you are making 
this demand because you have determined that your position is the 
only valid moral/ethical/legal position and any further 
discussion on the merits is therefore rendered moot. This is a 
highly unprofessional way to approach a deeply sensitive topic as 
it presumes that you, and those with whom you agree, are the sole 
arbiters of what is moral/ethical/legal and all other positions 
are *prima facie* immoral/unethical/illegal because you have 
determined it to be so.

Instead of making demands, I would strongly encourage you to 
engage in the discourse on the topic with an open mind and a 
learner's heart.

You may of course choose to leave, and there are a handful of 
languages that may meet your requirements. But if the D community 
chooses to allow LLM's then that is the community's choice and 
you do not have the right to demand otherwise.

Which gets to my last point. In my opinion, your demand of the 
DLF is misplaced. For the entire duration of my time in the D 
community, the community has always determined the direction of 
the DLF, and not the other way around. Therefore it is the 
community to whom you should be directing your demand. Not the 
DLF.

---------

Nothing in this post represents or is intended to represent the 
official position of the DLF. These are my thoughts, and my 
thoughts alone, on this topic.
Jul 04
next sibling parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Sunday, 5 July 2026 at 03:20:10 UTC, Adam Wilson wrote:

 because realistically, nobody actually cares how the code was 
 created


As far as I can tell Im the moderate, (*I dont like that*,) I 
think there was a forum post declaring the use of ai was a "grave 
mistake" maybe we could look it up, that person probably cares.

There should be an open letter floating around stating otherwise; 
its honestly 50/50.
Jul 04
parent reply Adam Wilson <flyboynw gmail.com> writes:
On Sunday, 5 July 2026 at 03:32:34 UTC, monkyyy wrote:

 On Sunday, 5 July 2026 at 03:20:10 UTC, Adam Wilson wrote:

 because realistically, nobody actually cares how the code was 
 created


 As far as I can tell Im the moderate, (*I dont like that*,) I 
 think there was a forum post declaring the use of ai was a 
 "grave mistake" maybe we could look it up, that person probably 
 cares.

 There should be an open letter floating around stating 
 otherwise; its honestly 50/50.


For context, I was speaking about the Linux Foundation. I thus 
amend that sentence to state "nobody *at the Linux Foundation* 
actually cares how the code was created."
Jul 04
parent monkyyy <crazymonkyyy gmail.com> writes:
On Sunday, 5 July 2026 at 03:45:18 UTC, Adam Wilson wrote:

 On Sunday, 5 July 2026 at 03:32:34 UTC, monkyyy wrote:

 On Sunday, 5 July 2026 at 03:20:10 UTC, Adam Wilson wrote:

 because realistically, nobody actually cares how the code was 
 created


 As far as I can tell Im the moderate, (*I dont like that*,) I 
 think there was a forum post declaring the use of ai was a 
 "grave mistake" maybe we could look it up, that person 
 probably cares.

 There should be an open letter floating around stating 
 otherwise; its honestly 50/50.


 For context, I was speaking about the Linux Foundation. I thus 
 amend that sentence to state "nobody *at the Linux Foundation* 
 actually cares how the code was created."


I bet there's plenty of drama in the d's newspaper of record, 
hackernews.

If we amending statements that are intentionally misleading, in 
light of 2 open letters, I would append my dip to *not* be about 
the legal concerns, that was me pushing safetyism buttons.

The ai question will need to be addressed tho.
Jul 04
prev sibling next sibling parent reply solidstate1991 <laszloszeremi outlook.com> writes:
On Sunday, 5 July 2026 at 03:20:10 UTC, Adam Wilson wrote:

 Do you really think a legal department would allow a 
 multi-trillion dollar company to blindly run into the biggest 
 potential legal minefield in decades without first having at 
 least spent a few man-decades of time figuring out all the ways 
 to NOT step on a mine?


"Move fast and break things, ask for forgiveness later."

These multi-trillion companies are filled with sycophants, and 
anyone dares to suggest in opposite of the mantra, get fired 
immediately. Since some people were complaining about lack of 
sources to my claims, here's one for Google's: 
https://www.wired.com/story/google-splits-up-responsible-innovation-ai-team/

There's also the issue of tech giants capturing at least the US 
government, ([this was the only article that nicely summarizes 
the 
issue](https://www.rosalux.de/en/news/id/54328/the-authoritarian-stack-mapping-big-techs-capt
re-of-state-power)) so there's a pretty good chance of big tech getting the
"get out of the jail free card" treatment for this too.

As for Linux: I think that happened due to sponsors having secret 
deals with the leadership. Sure, I don't know for sure, since I 
don't have an insight into them. But considering that 
[Weka](https://www.weka.io/) is involved in the AI push and is a 
sponsor of the DLF, I wonder if the free tokens are coming from 
them alongside with instructions to allow (or even force) AI into 
the codebase.
Jul 08
parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 08/07/2026 10:06 PM, solidstate1991 wrote:

 As for Linux: I think that happened due to sponsors having secret deals 
 with the leadership. Sure, I don't know for sure, since I don't have an 
 insight into them. But considering that Weka <https://www.weka.io/> is 
 involved in the AI push and is a sponsor of the DLF, I wonder if the 
 free tokens are coming from them alongside with instructions to allow 
 (or even force) AI into the codebase.


Free tokens? Lol

Only Adam has those, and that is only because he got a subscription at 
the right time. Then the pricing model changed to be token based.

He paid for that subscription too. No sponsorship involved.
Jul 08
prev sibling parent matheus <matheus gmail.com> writes:
On Sunday, 5 July 2026 at 03:20:10 UTC, Adam Wilson wrote:

 ...
 Do you really think a legal department would allow a 
 multi-trillion dollar company to blindly run into the biggest 
 potential legal minefield in decades without first having at 
 least spent a few man-decades of time figuring out all the ways 
 to NOT step on a mine?
 ...


I wouldn't bet too much on this if there is a lobby and some 
government will probably let this slip under the carpet to make 
their dominance acceptable in some areas.

Do you remember Ford Pinto's incident?

"The Ford Pinto incident refers to a notorious 1970s automotive 
controversy where the subcompact car's poorly designed fuel tank 
easily ruptured in low-speed rear-end collisions, causing deadly 
fires. Internal documents revealed that Ford Motor Company 
knowingly released the vehicle and delayed repairs because their 
calculations showed paying lawsuit settlements was cheaper than a 
$11 per-car recall."

Matheus.
Jul 08
prev sibling next sibling parent reply Anton Pastukhov <mail anton9.com> writes:
On Friday, 3 July 2026 at 10:55:19 UTC, solidstate1991 wrote:

 Setting aside artists' concerns about genAI automating away 
 part of the human experience, setting aside environmental 
 issues such as water and electricity usage, setting aside 
 social issues such as the accessibility of creating propaganda 
 in large amount, even setting aside issues from code quality, 
 which all will drive away potential users from the D ecosystem, 
 there's still one issue: licensing.


Wait, do D compilers and tools use LLMs extensively, in the full 
vibe-coding mode?
Jul 05
parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 05/07/2026 10:46 PM, Anton Pastukhov wrote:

 On Friday, 3 July 2026 at 10:55:19 UTC, solidstate1991 wrote:

 Setting aside artists' concerns about genAI automating away part of 
 the human experience, setting aside environmental issues such as water 
 and electricity usage, setting aside social issues such as the 
 accessibility of creating propaganda in large amount, even setting 
 aside issues from code quality, which all will drive away potential 
 users from the D ecosystem, there's still one issue: licensing.


 
 Wait, do D compilers and tools use LLMs extensively, in the full vibe- 
 coding mode?


No.

Nothing even remotely like that.

Just some bug fixes here and there that all get reviewed as if LLM's 
weren't involved.
Jul 05
parent reply Anton Pastukhov <mail anton9.com> writes:
On Sunday, 5 July 2026 at 10:48:57 UTC, Richard (Rikki) Andrew 
Cattermole wrote:

 On 05/07/2026 10:46 PM, Anton Pastukhov wrote:



 No.

 Nothing even remotely like that.

 Just some bug fixes here and there that all get reviewed as if 
 LLM's weren't involved.


That is... totally fine? I hate vibe coding as much as the next 
guy, but, given D's constant lack of manpower, using clankers for 
menial tasks should be OK.
Jul 05
parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 05/07/2026 11:19 PM, Anton Pastukhov wrote:

 On Sunday, 5 July 2026 at 10:48:57 UTC, Richard (Rikki) Andrew 
 Cattermole wrote:

 On 05/07/2026 10:46 PM, Anton Pastukhov wrote:


 

 No.

 Nothing even remotely like that.

 Just some bug fixes here and there that all get reviewed as if LLM's 
 weren't involved.


 
 That is... totally fine? I hate vibe coding as much as the next guy, 
 but, given D's constant lack of manpower, using clankers for menial 
 tasks should be OK.


Yeah.

There are somethings in the pipeline like arm inline assembler for dmd, 
and codeview update.

Those are bigger, but nothing big that has been merged that I am aware of.
Jul 05
next sibling parent Adam Wilson <flyboynw gmail.com> writes:
On Sunday, 5 July 2026 at 11:22:33 UTC, Richard (Rikki) Andrew 
Cattermole wrote:

 On 05/07/2026 11:19 PM, Anton Pastukhov wrote:

 That is... totally fine? I hate vibe coding as much as the 
 next guy, but, given D's constant lack of manpower, using 
 clankers for menial tasks should be OK.


 Yeah.

 There are somethings in the pipeline like arm inline assembler 
 for dmd, and codeview update.

 Those are bigger, but nothing big that has been merged that I 
 am aware of.


This run through the installers I've been been on to get FreeBSD, 
UCRT, and the nightlies working has been primarily LLM driven. 
I've done a little bit by hand where it was simple enough not to 
justify spending the money.

For the most part the LLM's have been handling these tasks quite 
well.
Jul 05
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/5/2026 4:22 AM, Richard (Rikki) Andrew Cattermole wrote:

 There are somethings in the pipeline like arm inline assembler for dmd, and 
 codeview update.


The arm assembler is very repetitive, as it deals with maybe 1000 twisty little 
instructions, all different.
Jul 07
prev sibling next sibling parent reply Lance Bachmeier <no spam.net> writes:
On Friday, 3 July 2026 at 10:55:19 UTC, solidstate1991 wrote:


 This means code that licensed GPL is in the training material, 
 and sometimes it can resemble the original code very closely, 
 see the FreeBSD exFAT driver, that was a bit less stable 
 regeneration of the Linux exFAT driver hacked onto FreeBSD. 
 Even worse is, that on the internet, we have both "source code 
 viewable" type solutions, and source code that has been 
 acquired through dubious means, to be then shared illegally 
 without the consent of the original writers.


This issue has little to do with AI. People were attempting to 
"relicense" code written by others long before we had the first 
LLM that was useful for coding. That was true even when 
Sourceforge was the dominant platform and it didn't start there. 
The only solution is to check all contributions for originality. 
That's a difficult task.


 Even if we get over these issues, there's the problem of code 
 quality. Sometimes vibe coded applications pass basic safety 
 checks, but then real-life tests prove those otherwise, and the 
 code is overinflated with extra lines and extra unnecessary 
 tricks.


Again, this is not specific to AI. Code review is always needed.


 GenAI code also led to an epidemic of "library slop": libraries 
 created just because someone could, not because of someone 
 needed them. Every time I thought of making a new library, I 
 checked what's available rather than diving deep into making 
 them myself. Now the new standard is making everything yourself 
 just because it's more trendy that way.


This is an excellent argument in favor of AI. I've attempted to 
run code from others that had more than a hundred dependencies 
that had to be installed. In some cases, it was hundreds of 
dependencies. I recently ran someone's Python code and had to 
create an environment with over 700 MB of dependencies. Most of 
the time, it's "I need this one small function, and I know it's 
in this library over here", so they add it as a dependency. That 
one library might have 25 dependencies of its own. If AI can rid 
us of this mess, the more AI the better.
Jul 06
parent reply Alexandru Ermicioi <alexandru.ermicioi gmail.com> writes:
On Monday, 6 July 2026 at 18:18:29 UTC, Lance Bachmeier wrote:

 This is an excellent argument in favor of AI. I've attempted to 
 run code from others that had more than a hundred dependencies 
 that had to be installed. In some cases, it was hundreds of 
 dependencies. I recently ran someone's Python code and had to 
 create an environment with over 700 MB of dependencies. Most of 
 the time, it's "I need this one small function, and I know it's 
 in this library over here", so they add it as a dependency. 
 That one library might have 25 dependencies of its own. If AI 
 can rid us of this mess, the more AI the better.


This someone has a bad balance of cost vs benefits ratio if he 
imports a behemoth just for it's toe.

Such things if possible should be rejected as soon as its seen.
Jul 08
parent reply Lance Bachmeier <no spam.net> writes:
On Wednesday, 8 July 2026 at 08:39:55 UTC, Alexandru Ermicioi 
wrote:

 On Monday, 6 July 2026 at 18:18:29 UTC, Lance Bachmeier wrote:

 This is an excellent argument in favor of AI. I've attempted 
 to run code from others that had more than a hundred 
 dependencies that had to be installed. In some cases, it was 
 hundreds of dependencies. I recently ran someone's Python code 
 and had to create an environment with over 700 MB of 
 dependencies. Most of the time, it's "I need this one small 
 function, and I know it's in this library over here", so they 
 add it as a dependency. That one library might have 25 
 dependencies of its own. If AI can rid us of this mess, the 
 more AI the better.


 This someone has a bad balance of cost vs benefits ratio if he 
 imports a behemoth just for it's toe.

 Such things if possible should be rejected as soon as its seen.


The context is an academic journal that requires authors to 
provide the code and data they used to get their results, so that 
all the details are out in public. I've been able to tell authors 
to remove unnecessary dependencies more often than you'd expect 
(including calls to expensive Matlab toolboxes that duplicated 
things done in base Matlab). I don't have the option to tell them 
to change working code. Authors have an incentive to get it done 
ASAP and they don't care if there are a few dozen dependencies 
that could have been avoided. I'm afraid LLMs are more prone 
rather than less to pull in dependencies.
Jul 13
parent monkyyy <crazymonkyyy gmail.com> writes:
On Monday, 13 July 2026 at 16:28:11 UTC, Lance Bachmeier wrote:

 
 incentive to get it done ASAP and they don't care if there are 
 a few dozen dependencies that could have been avoided. I'm 
 afraid LLMs are more prone rather than less to pull in 
 dependencies.


https://github.com/crazymonkyyy/ai-pomodoro/blob/6a55bfbe520c5b361fadb24cf69cc6e7a5adc28d/README.md?plain=1#L6

you should just state the acceptable dependency's, the main data 
types and any formats

It also just slower to use bad dependencies
Jul 13
prev sibling parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
On Friday, 3 July 2026 at 10:55:19 UTC, solidstate1991 wrote:

 result with extra lines. GenAI code also led to an epidemic of 
 "library slop": libraries created just because someone could, 
 not because of someone needed them. Every time I thought of 
 making a new library, I checked what's available rather than 
 diving deep into making them myself. Now the new standard is 
 making everything yourself just because it's more trendy that 
 way.


As someone who is/was waiting for libraries I need for my work 
for years (some even for decades), as I do not have time to 
implement them myself (also some of them I am not competent 
enough to write by myself), I can tell you that there is a 
bigger, and more subtle problem that you probably noticed too, 
but for some reason decided not to mention it. - Many D projects 
are done by single person who in most cases just barely scratched 
the surface and implemented bare minimum of whatever the library 
is supposed to do, examples are numerous. Often the scope is so 
big that developers just leave those projects in their "starting" 
state because they just "burned out". There are also those who 
implemented only what they need and clearly stated "this is it, 
if you want more, make PRs". Sure it is fair. Thing is, those 
projects often stay in the same state for years and are often 
simply abandoned.

LLMs give those people who do not want to wait 20 years for full, 
solid implementation of something to be finally released, 
opportunity to have a fully tested, working code, and if you are 
not convinced you can quickly add as many new tests as you think 
are necessary to get your full confidence in the project, or 
refactor part of the implementation to meet new criteria. This is 
what companies do currently anyway (those who embraced LLMs). 
Most of them still generate revenue last time I checked.

Finally, people should wonder why you can count companies using D 
with fingers on both hands, and that number is shrinking. - 
Because companies do not want to invest time, as "time is money", 
needed to have all the D "building blocks" for their projects 
ready on time, so they simply abandon the idea to use D and go 
back to a language they typically already use, that already has 
everything. As much as it pains me to say this, LLMs are D's last 
hope of becoming relevant again as they can help building 
necessary libraries fast enough for the ever-shrinking community 
(yes, I firmly believe D community is getting smaller 
year-by-year).
Jul 07
parent Dejan Lekic <dejan.lekic gmail.com> writes:
My reply was incorrectly formatted. Apologies. My reply actually 
starts with the `As someone who is/was waiting for libraries`. D 
forum should really need possibility to amend replies!
Jul 07