digitalmars.D - Making d actually usable by ai
- monkyyy (81/85) Aug 05 When writing full ai code ive been going with odin, it just keeps
- Serg Gini (18/21) Aug 06 my 50 cents:
- Richard (Rikki) Andrew Cattermole (9/30) Aug 06 Agreed, the D one is what I'd want.
- monkyyy (3/4) Aug 06 what an absurd assumption
- monkyyy (5/9) Aug 06 Structure *without a goal* is bad; it was never told anything to
- Kapendev (22/34) Aug 06 Well, I would call it a nice experience for noobs.
- Steven Schveighoffer (12/15) Aug 06 You are comparing apples to oranges.
- monkyyy (141/146) Aug 07 Its a one word difference in the prompt. No, bullshit.
- Serg Gini (30/34) Aug 07 ```
- monkyyy (113/116) Aug 07 As it always has been, and I have always criticized dub for,
- Mindy Batek (0xEAB) (4/8) Aug 07 «Apples» and «oranges» are both just one single word as well.
- Kapendev (30/39) Aug 07 I added two words and it changed my life.
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 guideExploring 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 guideEstablishing 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
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
On 06/08/2026 8:12 PM, Serg Gini wrote:On Thursday, 6 August 2026 at 02:13:56 UTC, monkyyy wrote: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."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
monkyyy <crazymonkyyy gmail.com> 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
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
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.jsonI 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
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
On Thursday, 6 August 2026 at 18:44:56 UTC, Steven Schveighoffer wrote:You are comparing apples to oranges.Its a one word difference in the prompt. No, bullshit.I've asked an LLM (the some one) the same question multiple times. ... This shows nothing of value.How many tries, what statistical method? How ought it be measured? Is it possible to met your standard? If I did it 10000 times odin was a 1 layer file hierarchy 99% and dlang was a 3(or greater) layer file hierarchy 99% of the time, would you really care?We ... (can't) change Dcan, you copy and paste files into the right place. Its this thing called programming, you type up some files that changes the way the machine gets executed. Really useful, I think that kid turing has a bright future with that "software" concept. --- 2nd: ``` my_raylib_game/ dub.sdl README.md .gitignore assets/ fonts/ textures/ audio/ source/ app.d core/ config.d assets.d logging.d game/ player.d enemy.d world.d systems.d ``` 3rd: ``` my-raylib-game/ ├── assets/ │ ├── fonts/ │ ├── images/ │ └── sounds/ ├── source/ │ ├── app.d │ ├── game/ │ │ └── game.d │ └── core/ │ └── config.d ├── dub.sdl └── .gitignore ``` ``` source/ app.d core/ config.d input.d resources.d game/ game.d player.d enemy.d render/ renderer.d sprite.d assets/ images/ fonts/ sounds/ ``` ``` assets/ images/ player/ enemies/ ui/ fonts/ sounds/ music/ sfx/ ``` (yes it did write out 3 different file structures, all nested) 4th: ``` my-raylib-game/ dub.json source/ app.d game/ player.d world.d input.d gfx/ renderer.d sprites.d core/ math.d time.d assets/ textures/ fonts/ audio/ ``` 5th: ``` my-raylib-game/ ├── assets/ │ ├── fonts/ │ ├── textures/ │ └── audio/ ├── source/ │ ├── app.d │ ├── game/ │ │ ├── state.d │ │ └── update.d │ ├── render/ │ │ └── draw.d │ └── assets/ │ └── assets.d ├── dub.sdl └── .gitignore ``` ``` source/ ├── app.d ├── game/ │ ├── state.d │ ├── update.d │ └── player.d ├── render/ │ ├── draw.d │ └── camera.d └── assets/ ├── textures.d └── audio.d ``` --- What is this vapid call for rigor and your fake defeatism, *its probably reading **your** install guide* a large percentage of the time. You personally could change your README.md to detail the steps for a dub-less project, maybe it would drop to 80%.
Aug 07
On Friday, 7 August 2026 at 08:33:51 UTC, monkyyy wrote:On Thursday, 6 August 2026 at 18:44:56 UTC, Steven If I did it 10000 times odin was a 1 layer file hierarchy 99% and dlang was a 3(or greater) layer file hierarchy 99% of the time, would you really care?``` I want to make a raylib project in odin write the first 5 steps and a style guide Here's a practical starting point for an Odin + raylib project that is easy to grow into a larger game. First 5 Steps 1. Create the project structure my_game/ ├── src/ │ ├── main.odin │ ├── game.odin │ ├── player.odin │ └── renderer.odin ├── assets/ │ ├── textures/ │ ├── audio/ │ ├── fonts/ │ └── shaders/ ├── build/ ├── third_party/ └── README.md Goal Keep source separate from assets. Avoid putting generated files in the repository ``` But what is your goal? You can't control other's AI.. We don't know the train data sample. I would suggest you to train your own model and use it :)
Aug 07
On Friday, 7 August 2026 at 08:55:57 UTC, Serg Gini wrote:But what is your goal?As it always has been, and I have always criticized dub for, multiple executables without designing a new git tree ``` ├── cli │ ├── bin │ │ ├── align │ │ ├── apply_alignment │ │ ├── apply_mask_edits │ │ ├── cell_extract │ │ ├── check_colorref │ │ ├── export │ │ ├── fuzz │ │ ├── recover_texture │ │ ├── run_qa │ │ ├── snap_palette │ │ ├── solve_light │ │ ├── solve_normals │ │ ├── suggest_palette │ │ ├── temp_align │ │ ├── temp_bio_walk │ │ ├── temp_bio_walk2 │ │ ├── temp_hue_field │ │ ├── temp_hue_vis │ │ ├── temp_lightspot │ │ ├── temp_maskextract_hue │ │ ├── temp_masks │ │ ├── temp_normals │ │ ├── temp_row_edges │ │ ├── temp_texture │ │ └── vote_mask │ ├── build.sh │ ├── src │ │ ├── align │ │ │ └── main.odin │ │ ├── apply_alignment │ │ │ └── main.odin │ │ ├── apply_mask_edits │ │ │ └── main.odin │ │ ├── cell_extract │ │ │ └── main.odin │ │ ├── check_colorref │ │ │ └── main.odin │ │ ├── common │ │ │ ├── args.odin │ │ │ ├── color_spaces.odin │ │ │ ├── config.odin │ │ │ ├── image.odin │ │ │ ├── json_util.odin │ │ │ ├── png_io.odin │ │ │ ├── prng.odin │ │ │ ├── qa.odin │ │ │ └── types.odin │ │ ├── export │ │ │ └── main.odin │ │ ├── fuzz │ │ │ └── main.odin │ │ ├── recover_texture │ │ │ └── main.odin │ │ ├── run_qa │ │ │ └── main.odin │ │ ├── snap_palette │ │ │ └── main.odin │ │ ├── solve_light │ │ │ └── main.odin │ │ ├── solve_normals │ │ │ └── main.odin │ │ ├── suggest_palette │ │ │ └── main.odin │ │ ├── temp_align │ │ │ └── main.odin │ │ ├── temp_bio_walk │ │ │ ├── main.odin │ │ │ └── temp_bio_walk │ │ ├── temp_bio_walk2 │ │ │ ├── main.odin │ │ │ ├── temp_bio_walk │ │ │ └── temp_bio_walk2 │ │ ├── temp_hue_field │ │ │ └── main.odin │ │ ├── temp_hue_vis │ │ │ └── main.odin │ │ ├── temp_lightspot │ │ │ └── main.odin │ │ ├── temp_maskextract_hue │ │ │ └── main.odin │ │ ├── temp_masks │ │ │ └── main.odin │ │ ├── temp_normals │ │ │ └── main.odin │ │ ├── temp_row_edges │ │ │ └── main.odin │ │ ├── temp_texture │ │ │ └── main.odin │ │ └── vote_mask │ │ └── main.odin │ └── visualizers.md ``` by all means show me a 25 executable project that uses dub; and notice the `temp_*` those were execution targets that got *1 paragraph prompts*. The npm mindset makes one gaint app with 1000 dependencies; maybe 1/4 of you yall tolerate the status quo and know how to escape it if you deem it worth doing for a project, but ai loses that taste and nuance for the median opinion.We don't know the train data sample.We do know, its not rocket surgery, they read "the internet", they grab "the internet", they search "the internet", they mimic opinions of "the internet" The word "style guide" is a risk for oo related vectors, with some weighting with the "official style guide of D"; both of which point the same way. We dont know the weighting of the training data but theres isn't a possible training run that can sum two vectors both pointing "left", to point "right".
Aug 07
On Friday, 7 August 2026 at 08:33:51 UTC, monkyyy wrote:On Thursday, 6 August 2026 at 18:44:56 UTC, Steven Schveighoffer wrote:«Apples» and «oranges» are both just one single word as well. Little things can make big differences. Especially when they are used to commission a huge probability software apparatus.You are comparing apples to oranges.Its a one word difference in the prompt.
Aug 07
On Friday, 7 August 2026 at 16:21:03 UTC, Mindy Batek (0xEAB) wrote:On Friday, 7 August 2026 at 08:33:51 UTC, monkyyy wrote:I added two words and it changed my life. ``` Grok: I want to make a raylib project in dlang WITHOUT DUB write the first 5 steps and a style guide my_raylib_project/ ├── source/ │ └── main.d ├── vendor/ │ └── raylib/ ← contents of raylib-d/source/raylib/ ├── lib/ ← raylib.dll / libraylib.so / .dylib + import libs (if not system-installed) └── (optional Makefile or build script) dmd -Ivendor source/main.d -L-Llib -L-lraylib -L-rpath=\$ORIGIN/lib -of=game ./game ``` The vendor folder can be removed, but not that bad. For fun, I asked it to do the same with Parin. ``` Grok: I want to make a Parin project in dlang WITHOUT DUB write the first 5 steps and a style guide Your project root now contains app.d, parin/, assets/, and the parin_package/ folder (keep it for the scripts). ./parin_package/scripts/run ``` I didn't include the style guide because it basically copy-pasted my `STYLE_GUIDE_D.md`. It really likes my markdown files.On Thursday, 6 August 2026 at 18:44:56 UTC, Steven Schveighoffer wrote:«Apples» and «oranges» are both just one single word as well. Little things can make big differences. Especially when they are used to commission a huge probability software apparatus.You are comparing apples to oranges.Its a one word difference in the prompt.
Aug 07