34
D is on the way of getting an AI slop standard library, for no good reason (feddit.org)
submitted 2 days ago by HaraldvonBlauzahn@feddit.org to c/programming@programming.dev
37 comments fedilink hide all child comments

cross-posted from: https://lemmy.world/post/49193875

DConf2026 mostly has proAI talks, with the biggest standout being Adam Wilson's talk about integrating LLMs into developing the next version of the standard library.

This lead to a lot of debate within the community, with even some pro-genAI people calling it out, and there's even an open letter calling for rethinking the use of genAI, and some increased interest in the OpenD fork. It is also found out that people did try to volunteer for the new standard library (including me), but were rejected with the excuse of "we already have things in the works".

I'm also interested into some D alternatives that's not Rust (🤮🤮🤮🤮🤮 - no I'm not a Lunduke fan, but a gamedev, also no "const by default" languages!), has metaprogramming capabilities, and no (mandatory) header files (🤮🤮🤮🤮🤮), in case I decide to leave. I have a game engine that could be ported, its resource management needs to decoupled for D's garbage collection though.

you are viewing a single comment's thread
view the rest of the comments
[-] mabeledo@lemmy.world 3 points 1 day ago* (last edited 1 day ago)

I was with you with the whole tooling thing until

RAD and "low code" tools, etc

These have always been terrible.

Anyway, my point here was, obviously, that producing larger and larger volumes of code faster, isn’t something desirable, and it has never been. You took this out of context, with the added injury of commenting on the follow up sentence… but I’m glad you did, because it clarified your position a lot.

Because you said that you would instruct a LLM to refactor code because you didn’t feel like doing it. The irony here is three fold:

  • You would leave a poorly written and unnecessary larger piece of code in your code base, which would increase development time as reviews would take longer, which was precisely the reason why you would want a human in the software engineering loop in the first place.
  • You claim that the LLM would refactor the code for you, but LLMs, in general, are designed with the implied requirement of maximizing token usage.
  • Later in your comment, you said that you don’t care about losing skills that “aren’t needed anymore”, but I wonder, isn’t this the kind of skill, i.e. refactoring inefficiently written code, that you would want a senior developer to maintain? Even more, in the long term, how would you guarantee that you could tell a good refactor from a bad one?

In short, I think you are wrong, but I don’t think you would know why until it bites you.

And further proof of it is this.

Even memory allocation is something you don't need to care about unless you're writing in C still.

This is why we get shitty software, Java apps that blow up once a week and websites that freeze your browser. Because “memory allocation is something you don’t need to care about”.

I guess it won’t make any difference if you replace your skills with a LLM, since it sure sounds like you didn’t have that many to begin with.

[-] atzanteol@sh.itjust.works 1 points 1 day ago

These have always been terrible.

Yeah - I'm not a fan of low-code stuff either.

Anyway, my point here was, obviously, that producing larger and larger volumes of code faster, isn’t something desirable, and it has never been. You took this out of context, with the added injury of commenting on the follow up sentence… but I’m glad you did, because it clarified your position a lot.

I'm not saying you want tools to produce "large volumes of code faster" though. Just that they do code faster. Sometimes that's deletion.

You took this out of context

Apologies - not my intent.

You would leave a poorly written and unnecessary larger piece of code in your code base, which would increase development time as reviews would take longer, which was precisely the reason why you would want a human in the software engineering loop in the first place.

We all make this trade-off. "Do I refactor this now and introduce risk and take more time, or do I leave it for now to be done later?" The LLM helps with the "take more time" component.

You claim that the LLM would refactor the code for you, but LLMs, in general, are designed with the implied requirement of maximizing token usage.

I... What? This isn't even wrong it's just weird. To begin with "token usage" has nothing to do with the amount of code in our code base, removing and modifying code also uses tokens. Secondly this just sounds far to "conspiracy theory" for me to entertain.

Later in your comment, you said that you don’t care about losing skills that “aren’t needed anymore”, but I wonder, isn’t this the kind of skill, i.e. refactoring inefficiently written code, that you would want a senior developer to maintain? Even more, in the long term, how would you guarantee that you could tell a good refactor from a bad one?

That's fair - better developers do and will continue to understand these things. Most developers, however, aren't "better" developers. But it's not a barrier to entry was my primary point.

In short, I think you are wrong, but I don’t think you would know why until it bites you.

I'm curious - what is it you think I'm wrong about?

this post was submitted on 09 Jul 2026
34 points (88.6% liked)

Programming

27651 readers
306 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 3 years ago
MODERATORS
snowe@programming.dev
Ategon@programming.dev
UlrikHD@programming.dev
bugsmith@programming.dev
Spyro@programming.dev