www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Making d actually usable by ai

reply monkyyy <crazymonkyyy gmail.com> writes:
When writing full ai code ive been going with odin, it just keeps 
being the right choice, the reason is extremely simple odin is 
correct on lib management d is not.

They ship raylib, if I were to ask ai to make a raylib project, 
take a wild geuss how its gonna do that; its going to grab dub 
and get into an npm mindset which is bad enough for a human, an 
unsupervised ai? No, it will do oo it will grab endless 
depencies, nononono; it will make a horrible mess. It will pick 
up the bad habits of an npm mindset, it will destory the file 
structure, and the good compiles times of the compiler wasted.

Instead of the good dependable raylib binding, our std has 
*checks notes* std.json

Ive now looking at the problems with string management in no-gc 
languages, its painful. Can we just clean up the language std and 
not infect the new users and the ai's *who cant learn better* 
with the worthless npm culture?

I repeat the ai's cant learn, they are the median opinion for 
whats around and what they "did", when they call dub they will be 
thinking like a js programmer, who outnumber us many many times 
over, thats going to be the sum of the vectors is their shitty 
taste. "Should I go import left-pad or write it myself beep boop 
its best practices to use the package manager".


```

 I want to make a raylib project in odin write the first 5 steps 
 and a style guide


Exploring the integration of raylib within Odin's ecosystem.
I am considering how Odin's foreign function interface and vendor 
management system facilitate access to external libraries like 
raylib.
The presence of a vendor directory suggests a structured approach 
to third-party dependencies, possibly including raylib through a 
dedicated module.
---

odin-raylib-game/
   main.odin
   assets/
   bin/
```

---
```

I want to make a raylib project in dlang write the first 5 steps 
and a style guide


Establishing a structured foundation for a D language game 
project leveraging raylib
I am defining a cohesive development environment by integrating 
essential system libraries and ensuring cross-platform 
compatibility through appropriate build tools.
I am organizing the project with clear module boundaries, 
consistent naming conventions, and a disciplined approach to code 
organization, error handling, and resource management.

---

my-raylib-game/
├── dub.sdl
├── .gitignore
├── .editorconfig
├── assets/
│   ├── textures/
│   ├── fonts/
│   ├── audio/
│   └── maps/
└── source/
     ├── app.d
     ├── core/
     │   ├── game.d
     │   ├── window.d
     │   └── assets.d
     ├── entities/
     │   ├── player.d
     │   └── enemy.d
     ├── states/
     │   ├── main_menu.d
     │   ├── gameplay.d
     │   └── pause.d
     └── rendering/
         ├── camera.d
         └── palette.d
```

look at the file structure, it thought dub and instantly made 
3-depth folders *before a line of code was written or goal 
stated*. To make ai behave better, we would need to implement 
some of the go/odin "programming language for a bad programmer" 
advice and extremely strong defaults is part of that. Arguing 
with an ai is like pushing water uphill; why should I start a 
project only to instantly need to fight with a idiot about file 
structure?
Aug 05
next sibling parent reply Serg Gini <kornburn yandex.ru> writes:
On Thursday, 6 August 2026 at 02:13:56 UTC, monkyyy wrote:

 When writing full ai code ive been going with odin, it just 
 keeps being the right choice, the reason is extremely simple 
 odin is correct on lib management d is not.


my 50 cents:
1) Odin is opinionated gamedev language, D is general purpose (D 
won)
2) dub is good (D won)
3) many people don't give a clue about raylib. One AAA gamedev I 
know said: raylib is opengl garbage, if you want something simple 
is better to get even SDL, at least it has Vulkan support
4) file structure of D's project is better (nice modularized 
structure which most of the games will need, instead of one file 
spaghetti garbage) (D won)
5) OO pushed for D with classes in different files with more 
clear and easy to work with structure. Even easier for AI - as it 
should not read large single file all the time, but will know 
that if it need to fix player - it will read player.d first, if 
enemy - enemy.d (D won)

So thanks to show us superiority of D compare to Odin :)
Its nice to know
Aug 06
next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 06/08/2026 8:12 PM, Serg Gini wrote:

 On Thursday, 6 August 2026 at 02:13:56 UTC, monkyyy wrote:

 When writing full ai code ive been going with odin, it just keeps 
 being the right choice, the reason is extremely simple odin is correct 
 on lib management d is not.


 
 my 50 cents:
 1) Odin is opinionated gamedev language, D is general purpose (D won)
 2) dub is good (D won)
 3) many people don't give a clue about raylib. One AAA gamedev I know 
 said: raylib is opengl garbage, if you want something simple is better 
 to get even SDL, at least it has Vulkan support
 4) file structure of D's project is better (nice modularized structure 
 which most of the games will need, instead of one file spaghetti 
 garbage) (D won)
 5) OO pushed for D with classes in different files with more clear and 
 easy to work with structure. Even easier for AI - as it should not read 
 large single file all the time, but will know that if it need to fix 
 player - it will read player.d first, if enemy - enemy.d (D won)
 
 So thanks to show us superiority of D compare to Odin :)
 Its nice to know


Agreed, the D one is what I'd want.

My guess is that the LLM is thinking for Odin that it is just doing 
project initialization, whereas for D its starting to build the full 
project and adding raylib dependency is just task 1.

Of course this is all due to monkyyy not using plans.

I suspect the solution here would be to modify the global prompt 
template to add something like: "do the minimal amount of work necessary 
to archive the goal(s), ignoring best practice and styling."
Aug 06
parent monkyyy <crazymonkyyy gmail.com> writes:
On Thursday, 6 August 2026 at 11:50:55 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 Of course this is all due to monkyyy not using plans.


what an absurd assumption
Aug 06
prev sibling parent monkyyy <crazymonkyyy gmail.com> writes:
On Thursday, 6 August 2026 at 08:12:54 UTC, Serg Gini wrote:

 
 4) file structure of D's project is better (nice modularized 
 structure which most of the games will need, instead of one 
 file spaghetti garbage)


Structure *without a goal* is bad; it was never told anything to 
work on yet already made structural decisions *that make my 
projects harder*.

Complexity is THE COST not the goal itself.
Aug 06
prev sibling next sibling parent Kapendev <alexandroskapretsos gmail.com> writes:
On Thursday, 6 August 2026 at 02:13:56 UTC, monkyyy wrote:

 When writing full ai code ive been going with odin, it just 
 keeps being the right choice, the reason is extremely simple 
 odin is correct on lib management d is not.


Well, I would call it a nice experience for noobs.
I personally am not a fan of locking a dependency to a language 
version.
That's why I also like things to stay outside of standard 
libraries in general.
Just git clone and done.



 They ship raylib, if I were to ask ai to make a raylib project, 
 take a wild geuss how its gonna do that; its going to grab dub 
 and get into an npm mindset which is bad enough for a human, an 
 unsupervised ai? No, it will do oo it will grab endless 
 depencies, nononono; it will make a horrible mess. It will pick 
 up the bad habits of an npm mindset, it will destory the file 
 structure, and the good compiles times of the compiler wasted.


You can start your prompt with: "Mister AI, please avoid DUB and 
git clone my deps."
AIs are dumb, you need to help them a little.
Be nice to them.
Buy them some milk.


 Instead of the good dependable raylib binding, our std has 
 *checks notes* std.json


I like raylib too, but I would prefer something like adr's simple 
display in the standard library.
Avoiding C bindings in the std is a good thing.
For example, the safe thing to do in Odin if you want your 
project to be version-agnostic is to **vendor the vendor 
libraries**.
So we are basically git cloning again, but worse because I can't 
use a tag or other git features.

That's my input on this.
Arigato.
Aug 06
prev sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On Thursday, 6 August 2026 at 02:13:56 UTC, monkyyy wrote:

 When writing full ai code ive been going with odin, it just 
 keeps being the right choice, the reason is extremely simple 
 odin is correct on lib management d is not.


You are comparing apples to oranges.

An LLM can make different decisions for different situations, or 
different decisions for the *exact same* situation.

I've asked an LLM (the some one) the same question multiple 
times. Sometimes it gives me a short one-line answer which gets 
to the point. Sometimes it gives me 10 point presentation with 
receipts.

This shows nothing of value. But it's fine if you think it does 
and pick Odin instead. We aren't (can't) change D to "conform" to 
the whims of an LLM's performance.

-Steve
Aug 06