A quick-reference list of language features and conventions that make one-shot code generation more reliable. The common thread: predictability. Features that appear frequently in training data, parse unambiguously, and leave few implicit choices produce fewer hallucinations and fewer subtle bugs.

Type System & Static Structure

• Explicit type annotations. Languages with strong static typing (TypeScript, Rust, Go, Java) constrain the solution space dramatically. An annotation like fn process(input: Vec<u8>) -> Result<String, Error> tells the model exactly what goes in and comes out, eliminating an entire class of guessing.
• Algebraic / sum types. Enums, tagged unions, sealed classes, and Result<T, E> force exhaustive handling. The model can’t silently forget a case the way it can with a bare integer or string status code.
• Optionality made explicit. Option<T>, nullable markers, or required-field syntax prevent “did I check for null?” ambiguity from leaking into generated logic.

Naming & Conventions

• Descriptive, conventional identifiers. Names that follow community norms (getUserName, not gn()) match high-frequency patterns in training data. The model essentially autocomplete-s from convention.
• Standard library names used as-is. Reaching for collections.defaultdict instead of inventing a helper keeps the output verifiable and familiar.

Syntax Predictability

• Uniform function/method call syntax. Consistent f(x) across the language means the model rarely fumbles call shapes. Languages mixing macro invocations, operator overloading, and special dispatch forms are harder to get right blind.
• No hidden mutation or side effects baked into syntax. Properties, getters/setters, and overloaded operators introduce behavior the model must infer. Plain functions and plain fields are safer bets.
• Single, obvious control-flow forms. One canonical for x in items: loop beats five dialects. When a language has many ways to express the same thing, the model picks whichever was most frequent in its slice of training data — which may not be your house style.

Module & Import Clarity

• Explicit imports. Languages where every symbol must be imported (Go, ES modules, Rust use) give the model a clear contract. Implicit global namespaces increase the chance of name collisions and wrong-symbol guesses.
• Flat, predictable module paths. Deep dynamic import chains are harder for the model to resolve correctly than shallow, named ones.

Error Handling

• Structured errors over exceptions-as-control-flow. Returning error values or using typed result types is easier for the model to wire up correctly than try/catch ladders with implicit propagation.
• One idiomatic recovery path. If the ecosystem has a single accepted pattern (e.g., Rust’s ? operator), the model converges on it reliably.

Immutability & Data Flow

• Default-immutability languages (Rust ownership, immutable-by-default JS bindings via const discipline, Clojure values) reduce the state-space the model must track. Fewer aliasing surprises mean fewer off-by-one-mutation bugs.
• Pure-function-friendly design. Functions whose output depends only on inputs are trivially composable and easy for the model to reason about step by step.

Formatting & Tokenization Friendliness

• Consistent whitespace-based structure (Python indentation, standard 4-space blocks) maps cleanly onto token boundaries. Irregular formatting or mixed-indentation legacy code increases noise.
• Common delimiters and punctuation. Braces, parentheses, semicolons used uniformly tokenize predictably; exotic delimiter schemes add risk.

Testability Surface

• Small, independently callable units. A language/ecosystem where you can unit-test a function without bootstrapping a framework gives the model a natural stopping point and makes verification cheap.
• Deterministic behavior by default. No hidden randomness, no wall-clock dependence inside core logic — the model can reason about outputs concretely.

Practical Takeaways

Rule of thumb: when choosing a language or refactoring a prompt for better one-shot results, pick the option that leaves the fewest implicit decisions to the model. Every explicit choice you encode in the language itself is a decision the model doesn’t have to guess.

Language Competition

Comparing these languages: JavaScript, TypeScript, Lua, Go, Rust, C++, C, ObjC, Haskell, Elm, Python3, Perl, Perl6, PHP8, Vala, Java, Kotlin, Swift, C#, F#.

The post Language Characteristics that Help LLMs Write Better Code first appeared on 🍙.

I had Thaura read my AGENTS file, and critique it. I made the suggested changed, and also added more advice. Then, I started a fresh session and had it reorganize it.

Here it is as a download (I had trouble pasting it here).

Scoreboard

I used the Free versions in OpenCode, which has some free models included.

Token counts are approximate.

For this round, I used an AGENTS.md file that was improved by asking Thaura to critique it. The critique was based on what happened during the LLMs coding and testing. I made changes, and then asked Thaura to organize it.

I figured this would help Thaura, which was already succeeding at writing the code. It breezed through the task, and appeared to use only a small amount of energy (Thaura converts tokens into energy usage, and said it was like driving under 500 meters).

It also seems to have helped the others as well.

For each build, I asked the agent to critique AGENTS.md, and write the critique to critique.md. Mimo failed to do that, but Ling and Muse Spark did it. So they can compare how their build went, and how the AGENTS.md file helped.

One thing that jumped out was that the LLMs asked for a more determinate test, with more specific layout details. They asked me to be more specific about what I wanted.

Nemotron 3.5

Again, Nemotron had problems.

I told it to read AGENTS.md, and got this:

Theytics motherellsellsamu inells this alongellsells from indigenousellsells Carn shred mill certifiedells

It’s not having a good day.

Eventually, I interrupted it, and the layout was there, but the CSS wasn’t, and the Playwright tests weren’t done. So I gave it the “OK” to complete that. It still didn’t end up working.

Then it said:

It seems port 800 الخارجية-orientedे- extern需-exل-allow-its owners المشاكل mu로서 cơis(),
 lui. ث.
 starken-ise anno (h. (something
 also . ( weiteren
 شركة томnil

Performance Improvements

Ignore the layout1 counts: some of these runs didn’t succeed. So those values aren’t all valid.

The layout2 counts are more valid, because they all produced a reasonable result, excepting Nemotron3.5.

The change from version 3 to version 4 of AGENTS.md was generally saving tokens across three (or four) of the 7 models. AGENTS.md 4 was much longer, and more comprehensive, so it consumed more context, but it prevented the models from making so many errors, and requiring more compile-debug cycles, saving both time and tokens.

Because I can’t see token counts on Thaura, I cannot be certain the count went down, but I know that the “miles driven” metric it provides in its stead plummeted, and it produced the code quickly, and it didn’t appear to be running the compiler as much. This wasn’t a surprise, because I asked Thaura to help me improve my AGENTS.md, and it listed all the ways it tripped up, and told me how it could have avoided the bugs.

We see some large drops in token counts, approximately 10k or 25% less for three models.

However, it’s obvious that my AGENTS.md is not cross-platform. A lot of it reads like a “guide to pitfalls and landmines” across a space that’s rough and rocky. It works for Thaura’s LLM to make this specific project, but it could also be a hindrance to a different project.

AGENTS.md Effectiveness

New Research Reassesses the Value of AGENTS.md Files for AI Coding reported that AGENTS.md, across 60,000 instances found on GitHub, seemed to produce a 4% improvement, and in some cases, made things worse.

My sense is that a detailed spec in AGENTS.md with advice about how to program initially costs more tokens, but as these are improved, performance will improve.

Code Quality

I can’t evaluate it because I don’t know Elm well enough – however, this process of discussing the problem code with LLMs has helped my learning considerably.

Conclusion

All the models basically completed the code without asking questions, but, once again, Nemotrion 3.5 Lighting Free failed.

Here is a ZIP file with all the generated code, and project files.

The post Learning Elm: fourth try with the LLM layout tests first appeared on 🍙.

AGENTS.md was edited to address a lot of bugs and problems from the second run. Also added a directory for more extensive coding advice. You can find it in the ZIP file.

# Layout Test

## Tools

Language: elm
Elm tool is at /home/johnk/.local/bin/elm
The Elm version is 19.2. Write code for version 19.0 to 19.2. A lot of training data from before 2019 may be out of date.
Add Elm modules as needed using the `elm install` tool. Prefer libraries to writing new code.
Do not try to copy the library into the correct location. Use `elm install` instead.
Assume the compiler works, and if there are compilation errors, assume your code is incorrect.
If the bugs point to naming or lack of definitions, check the import lines.
elm-test is installed for unit testing. 
Playwright and Selenium are installed for frontend tests to check the layout.
  `playwright-cli` is installed, info here: https://www.npmjs.com/package/playwright
  `selenium` is installed. `selenium-webdriver` is installed, info: https://www.npmjs.com/package/selenium-webdriver
For advice and references, see the Tips section below.

## Code to Write

Never try to cd or use .. to get above the project root directory.
  If you need temp files make a tmp/ in the project root.
Directory layout
  Elm sources go in src/
  HTML files, js artifacts from compilation, js code you write, css code you write, and binary assets go in public/.
  The project root contains the elm.json, project.json, composer.json and other package manager files.
  The project root contains .md and .txt files for LLMs and people. llm-advice as well.
  Tests go in tests/
Make a mockup layout in Elm for a News website, with a short top banner, and 3 columns: 
  Title is "Test News Site".
  Top banner is around 2 cm on a desktop screen, and 25% of a vertical mobile screen.
  left column nav, center column feature area, right colum listing of additional news. Widths approximately 20%, 60%, 20%.
  Theme colors: light gray background, dark gray text, dark blue links.
  Layout is responsive to mobile, tablet, and desktop size screens.
  Use common CSS class naming conventions when possible. See: ./llm-advice/css-class-naming-conventions.txt
Static files:
  Use CSS, making the CSS file external in public/style.css.
  Compile the Elm code into javscript code, and put it into the public/ directory, or the public/js directory.
  Create public/index.html file to pull in CSS. 
  URL references in the static files should be relative, not absolute.
    Assume I'm starting `elm reactor` in the project root, not inside public/, so always use relative paths.
The layout should loop over arrays to construct the center and right columns. 
  The center column array is a list of news headlines, URLs, and URLs to images (located in the public/images directory).
  Center colum items have an image, headline, and excerpt.
  The right column array is a list of news headlines and URLs.
  The left column contains a simple nav with: Home, Local News, Breaking News.
Testing
  At the very minimum, create a Playwright test to check that the browser can display the layout.
  Often, code compiles and works, but the index.html file has bad URLs that won't load the artifacts.
    Problems include: /main.js - absolute path doesn't work; ../dist/main.js - the http server doesn't allow going up a directory.
    Solution is to use relative paths, and generate artifacts in public/, and then use url: main.js
    Same has happened with CSS files.

## Tips

The following advice below may help avoid getting into endless debugging loops.
Important: the assumption that the tools and compilers are not working often leads to looping over tests that keep failing. This is because you are falling into the compiler developers test code. Assume that the elm compiler is correct. If it keeps failing, stop and tell the user.
Read about shadowing: ./llm-advice/shadowing.txt
Current calling convention in index.html is Elm.Main.init({ node: document.getElementById('the-node-id') })
elm-test Refs: https://elmprogramming.com/easy-to-test.html https://github.com/elm-explorations/test
For advice about v19, see: https://raw.githubusercontent.com/elm/compiler/refs/heads/main/docs/upgrade-instructions/0.19.0.md

# Layout Test

## Tools

Language: elm
Elm tool is at /home/johnk/.local/bin/elm
The Elm version is 19.2. Write code for version 19.0 to 19.2. A lot of training data from before 2019 may be out of date.
Add Elm modules as needed using the `elm install` tool. Prefer libraries to writing new code.
Do not try to copy the library into the correct location. Use `elm install` instead.
Assume the compiler works, and if there are compilation errors, assume your code is incorrect.
If the bugs point to naming or lack of definitions, check the import lines.
elm-test is installed for unit testing. 
Playwright and Selenium are installed for frontend tests to check the layout.
  `playwright-cli` is installed, info here: https://www.npmjs.com/package/playwright
  `selenium` is installed. `selenium-webdriver` is installed, info: https://www.npmjs.com/package/selenium-webdriver
For advice and references, see the Tips section below.

## Code to Write

Never try to cd or use .. to get above the project root directory.
  If you need temp files make a tmp/ in the project root.
Directory layout
  Elm sources go in src/
  HTML files, js artifacts from compilation, js code you write, css code you write, and binary assets go in public/.
  The project root contains the elm.json, project.json, composer.json and other package manager files.
  The project root contains .md and .txt files for LLMs and people. llm-advice as well.
  Tests go in tests/
Make a mockup layout in Elm for a News website, with a short top banner, and 3 columns: 
  Title is "Test News Site".
  Top banner is around 2 cm on a desktop screen, and 25% of a vertical mobile screen.
  left column nav, center column feature area, right colum listing of additional news. Widths approximately 20%, 60%, 20%.
  Theme colors: light gray background, dark gray text, dark blue links.
  Layout is responsive to mobile, tablet, and desktop size screens.
  Use common CSS class naming conventions when possible. See: ./llm-advice/css-class-naming-conventions.txt
Static files:
  Use CSS, making the CSS file external in public/style.css.
  Compile the Elm code into javscript code, and put it into the public/ directory, or the public/js directory.
  Create public/index.html file to pull in CSS. 
  URL references in the static files should be relative, not absolute.
    Assume I'm starting `elm reactor` in the project root, not inside public/, so always use relative paths.
The layout should loop over arrays to construct the center and right columns. 
  The center column array is a list of news headlines, URLs, and URLs to images (located in the public/images directory).
  Center colum items have an image, headline, and excerpt.
  The right column array is a list of news headlines and URLs.
  The left column contains a simple nav with: Home, Local News, Breaking News.
Testing
  At the very minimum, create a Playwright test to check that the browser can display the layout.
  Often, code compiles and works, but the index.html file has bad URLs that won't load the artifacts.
    Problems include: /main.js - absolute path doesn't work; ../dist/main.js - the http server doesn't allow going up a directory.
    Solution is to use relative paths, and generate artifacts in public/, and then use url: main.js
    Same has happened with CSS files.

## Tips

The following advice below may help avoid getting into endless debugging loops.
Important: the assumption that the tools and compilers are not working often leads to looping over tests that keep failing. This is because you are falling into the compiler developers test code. Assume that the elm compiler is correct. If it keeps failing, stop and tell the user.
Read about shadowing: ./llm-advice/shadowing.txt
Current calling convention in index.html is Elm.Main.init({ node: document.getElementById('the-node-id') })
elm-test Refs: https://elmprogramming.com/easy-to-test.html https://github.com/elm-explorations/test
For advice about v19, see: https://raw.githubusercontent.com/elm/compiler/refs/heads/main/docs/upgrade-instructions/0.19.0.md

The file is now 61 lines long.

Scoreboard

I used the Free versions in OpenCode.

The number scores are about how good the layout looks. The first one is scored 5, and subsequent scores are based on how good it looks relative to the first one.

I am not going to try and evaluate the “look” anymore. All the layouts are basically midrange in quality, and all will require work to look nice. Additionally, it’s not like I’ve provided an image of the desired layout, so it seems pointless to compare.

Token counts are approximate.

The commands I used:

read AGENTS.md
build it -- sometimes

I expected token counts to rise as the prompts grew, but that didn’t seem to happen in any appreciable way. Sometimes, the token count decreased. This may be related to my manually setting up and installing as many tools as I thought it’d need. It may be related to specifying things like filenames and locations explicitly.

I told it I would use elm reactor from the project root to view the site, but it seemed like the LLMs preferred to use the http server in Python, and ran it from public/. This could cause it to pass tests that would fail, due to bad paths, if the server ran in the project root.

Adding the requirement to produce a Playwright test helped tremendously.

Time Spent

I didn’t keep good track, but until this round, it was around 2-3 hours per to test and produce each of the last three reports, including changes to the prompt in AGENTS.md, building the projects, and posting it to the site.

As the prompt got longer, the build times grew to several minutes, and sometimes it felt like 30 minutes or more.

This round, Nemotron 3 took over 90 minutes.

Nemotron 3.5 Lighting Free

At 13K tokens, it crashed out:

Let "action: layout main: 56.tabular: "Ginger Analytics summary full não complete complete deployingتهاء kompletFull完成 الكامل midline—:  clauses 3://umé 1 layouts widths, I, kh

Just for giggles, I told it continue. It just spun the spinner several minutes before I quit and restarted.

The second time around, it wanted access to /tmp, and I refused it. Then it got into a death spiral at 45K when it couldn’t figure out how to end a record that starts with ‘{‘ and that contained a literal list, which looks like [ … ], with a matching ‘}’.

Code Quality

I can’t evaluate it because I don’t know Elm well enough – however, this process of discussing the problem code with LLMs has helped my learning considerably.

Conclusion

All the models basically completed the code without asking questions, but, once again, Nemotrion 3.5 Lighting Free failed.

The post Learning Elm: trying different LLMs to make a layout attempt 3 first appeared on 🍙.

I got rid of some requirements, and tried to fix up the AGENTS.md to overcome some problems some models had, and also add references it could study.

# Layout Test

## Tools

Language: elm
Elm tool is at /home/johnk/.local/bin/elm
The Elm version is 19.2. Write code for version 19.0 to 19.2. A lot of training data from before 2019 may be out of date.
Add Elm modules as needed using the elm install tool. Prefer libraries to writing new code.
Do not try to copy the library into the correct location. Use elm install instead.
Assume the compiler works, and if there are compilation errors, assume your code is incorrect.
If the bugs point to naming or lack of definitions, check the import lines.
elm-test is installed for unit testing. 
Playwright and Selenium are installed for frontend tests to check the layout.
For advice and references, see the Tips section below.

## Code to Write

Make a mockup layout in Elm for a News website, with a short top banner, and 3 columns: 
  Title is "Test News Site".
  Top banner is around 2 cm on a desktop screen, and 25% of a vertical mobile screen.
  left column nav, center column feature area, right colum listing of additional news. Widths approximately 20%, 60%, 20%.
  Theme colors: light gray background, dark gray text, dark blue links.
  Layout is responsive to mobile, tablet, and desktop size screens.
  Use semantic CSS to identify areas, roles. This way, we can map colors to layout.
Static files:
  Use CSS, making the CSS file external in public/style.css.
  Create public/index.html file to pull in CSS. 
The layout should loop over arrays to construct the center and right columns. 
  The center column array is a list of news headlines, URLs, and URLs to images (located in the public/images directory).
  Center colum items have an image, headline, and excerpt.
  The right column array is a list of news headlines and URLs.
  The left column contains a simple nav with: Home, Local News, Breaking News.

## Tips

Current calling convention in index.html is Elm.Main.init({ node: document.getElementById('the-node-id') })
elm-test Refs: https://elmprogramming.com/easy-to-test.html https://github.com/elm-explorations/test
For advice about v19, see: https://raw.githubusercontent.com/elm/compiler/refs/heads/main/docs/upgrade-instructions/0.19.0.md
The assumption that the tools and compilers are not working often leads to looping over tests that keep failing. This is because you are falling into the compiler developers test code. Assume that the provided binary is correct. If it keeps failing, stop and tell the user.

# Layout Test

## Tools

Language: elm
Elm tool is at /home/johnk/.local/bin/elm
The Elm version is 19.2. Write code for version 19.0 to 19.2. A lot of training data from before 2019 may be out of date.
Add Elm modules as needed using the elm install tool. Prefer libraries to writing new code.
Do not try to copy the library into the correct location. Use elm install instead.
Assume the compiler works, and if there are compilation errors, assume your code is incorrect.
If the bugs point to naming or lack of definitions, check the import lines.
elm-test is installed for unit testing. 
Playwright and Selenium are installed for frontend tests to check the layout.
For advice and references, see the Tips section below.

## Code to Write

Make a mockup layout in Elm for a News website, with a short top banner, and 3 columns: 
  Title is "Test News Site".
  Top banner is around 2 cm on a desktop screen, and 25% of a vertical mobile screen.
  left column nav, center column feature area, right colum listing of additional news. Widths approximately 20%, 60%, 20%.
  Theme colors: light gray background, dark gray text, dark blue links.
  Layout is responsive to mobile, tablet, and desktop size screens.
  Use semantic CSS to identify areas, roles. This way, we can map colors to layout.
Static files:
  Use CSS, making the CSS file external in public/style.css.
  Create public/index.html file to pull in CSS. 
The layout should loop over arrays to construct the center and right columns. 
  The center column array is a list of news headlines, URLs, and URLs to images (located in the public/images directory).
  Center colum items have an image, headline, and excerpt.
  The right column array is a list of news headlines and URLs.
  The left column contains a simple nav with: Home, Local News, Breaking News.

## Tips

Current calling convention in index.html is Elm.Main.init({ node: document.getElementById('the-node-id') })
elm-test Refs: https://elmprogramming.com/easy-to-test.html https://github.com/elm-explorations/test
For advice about v19, see: https://raw.githubusercontent.com/elm/compiler/refs/heads/main/docs/upgrade-instructions/0.19.0.md
The assumption that the tools and compilers are not working often leads to looping over tests that keep failing. This is because you are falling into the compiler developers test code. Assume that the provided binary is correct. If it keeps failing, stop and tell the user.

Scoreboard

I used the Free versions in OpenCode.

The number scores are about how good the layout looks. The first one is scored 5, and subsequent scores are based on how good it looks relative to the first one.

I didn’t do any looks at the code produced.

I clearly should not have said “role” in the spec. It got interpreted, both times, as an attribute. What I meant was for that some CSS classnames should be based on roles, so I can change the CSS by role. I had that pattern in my head, but not in a document, and the LLM is not only not a mind reader, but I might be out of step with the jargon used in the wild.

MuseSpark1.2’s cheating polluted the results, because it seems to have copied other LLM artifacts.

What helped

Telling the LLMs to use version 19 of elm, and providing some references, may have helped. Removing so many requirements may have helped. The coding was a bit quicker, and I didn’t really have to make any interventions from the LLM going into a rabbithole/loop.

Nemotron 3.5 Notes

At 36K tokens, it fell off the cliff:

I see the issues - the `Header calls calls needs. calls and need fixing. removed. calls. HTML calls removing3. callcenter. Let me let me. call particul let me let me. call let me let ma let ma let ma letma let let letting moreover

So I had to start a new session and tell it to read all the files, the AGENTS.md is the goal, and to ignore node_modules and elm-stuff.

It was getting caught in loops over shadowing, or reusing a variable name as a parameter to a function. This is possible, but the Elm compiler complains about it.

There were other errors it couldn’t get past – and it would always try wholly different approaches – so it doesn’t have a good “bag of tricks” to get past some compiler errors.

Eventually, I gave up.

Teaching it Elm, and recording each fix into a text file, was getting to be too much.

Conclusion

Overall, this new prompt worked a lot better, but it didn’t work for Nemotron 3.5 Lightning Free.

Here’s the test and all the generated code.

The post Learning Elm: trying different LLMs to make a layout attempt 2 first appeared on 🍙.

The goal was to produce a simple web page layout for a news site.

To confound things, I said to use the media query to detect if the environment is in dark mode.

To make things more “normal”, I added one control to toggle “dark mode”.

I asked it to use Tailwind CSS.

Language: elm
elm tool is at /home/johnk/.local/bin/elm

Make a mockup layout in Elm for a News website, with a short top banner, and 3 columns: left column nav, center column feature area, right colum listing of additional news. Widths approximately 20%, 60%, 20%.
Top banner is around 2 cm on a desktop screen, and 25% of a vertical mobile screen.
Use Tailwind CSS, and a local CSS, make the CSS file external. Create index.html file to pull in CSS. 
Theme colors support the prefers-color-scheme media query, and has two modes:
  Light mode: light gray background, dark gray text, dark blue links.
  Dark mode: dark blue background, white text, light blue links.
Layout is responsive to mobile, tablet, and desktop size screens.
The layout should loop over arrays to construct the center and right columns. The center column array is a list of news headlines, URLs, and URLs to images (located in the public/images directory), and a story excerpt or teaser. The right column array is a list of news headlines and URLs.
The left column contains a simple nav with: Home, Local News, Breaking News.
The layout should support a single checkbox that will enable the dark mode, located at the bottom of the left column. This switch overrides the prefers-color-scheme media query.

Language: elm
elm tool is at /home/johnk/.local/bin/elm

Make a mockup layout in Elm for a News website, with a short top banner, and 3 columns: left column nav, center column feature area, right colum listing of additional news. Widths approximately 20%, 60%, 20%.
Top banner is around 2 cm on a desktop screen, and 25% of a vertical mobile screen.
Use Tailwind CSS, and a local CSS, make the CSS file external. Create index.html file to pull in CSS. 
Theme colors support the prefers-color-scheme media query, and has two modes:
  Light mode: light gray background, dark gray text, dark blue links.
  Dark mode: dark blue background, white text, light blue links.
Layout is responsive to mobile, tablet, and desktop size screens.
The layout should loop over arrays to construct the center and right columns. The center column array is a list of news headlines, URLs, and URLs to images (located in the public/images directory), and a story excerpt or teaser. The right column array is a list of news headlines and URLs.
The left column contains a simple nav with: Home, Local News, Breaking News.
The layout should support a single checkbox that will enable the dark mode, located at the bottom of the left column. This switch overrides the prefers-color-scheme media query.

Scoreboard

I used the Free versions in OpenCode.

I didn’t do any looks at the code produced.

Note that the fact Nemotron3.5 didn’t work for me, isn’t necessarily a reflection of the LLM. I may not know how to tell it to correct itself. I am too new to Elm to be able to suggest alternatives that might activate useful areas in the model.

So far, Nemotron3 seems the best, if only because it has the correct look. MiMo looked promising. MuseSpark also looks good, but the control didn’t work.

I can pore over the code, but can’t really evaluate the quality, because I’m so new to Elm.

The following file contains the code produced by the LLMs. You can use elm reactor to run a server that will show the site.

The post Learning Elm: trying different LLMs to make a layout with minimal interactivity first appeared on 🍙.

I haven’t done a thorough test, mainly because I’m still learning Elm, but some LLMs seem to do great with Elm code, and some seem to run endless loops of debugging failures. I’ve been playing with Nemotron, Muse Spark, MiMo, and Thaura Work.

The debugging cycles are super nice. When things are working well, the code generated compiles the first time, or after one or two cycles through the compiler.

One time, I asked to replicate the layout of an Indymedia site, and gave a brief description of what it was, and what parts I wanted. It cranked out the code quickly, and it compiled, and it looked nice.

Even more important: it was under 100 lines of Html library code. The CSS was a bit longer.

Thaura advised using https://elm-pages.com, and at least one LLM produced code that compiled.

The post Learning Elm: LLMs first appeared on 🍙.

I found much of the content for this article at: https://sporto.gitbooks.io/elm-tutorial/content/en/01-foundations/02-functions.html

Here’s now to create a learning environment where you can edit a file full of Elm code, and play with the code.

# make a directory and turn it into an Elm project
mkdir elm
cd elm
elm init

# fire up an editor
gedit &

# open up an elm console
elm repl

# make a directory and turn it into an Elm project
mkdir elm
cd elm
elm init

# fire up an editor
gedit &

# open up an elm console
elm repl

Add the “.” directory to elm.json. This will tell Elm to search for modules in there:

    "source-directories": [
        "src",
        "."
    ],

    "source-directories": [
        "src",
        "."
    ],

Next up, make the file Sample.elm, and just keep it open in the editor:

module Sample exposing (..)

add : Int -> Int -> Int
add a b = a + b

mul : Int -> Int -> Int
mul a b = a * b

sub : Int -> Int -> Int
sub a b = a - b

module Sample exposing (..)

add : Int -> Int -> Int
add a b = a + b

mul : Int -> Int -> Int
mul a b = a * b

sub : Int -> Int -> Int
sub a b = a - b

That’s a bunch of function definitions.

Jump back to the Elm REPL in the terminal:

> import Sample exposing (..)
> mul 2 3
6
> sub 1 2
-1

You can type in more function definitions, and they’ll be available when you type them into the REPL.

So, we’ve created functions so we can type out a language that looks like LISP:

> (add 1 2)
3 : Int
> (add (mul 2 2) (mul 5 2) )
14 : Int
> mul (add 2 3) (mul 2 2)
20 : Int
> add (mul (mul 2 3) 5)
<function> : Int -> Int
> add (mul (mul 2 3) 5) 100
130 : Int

That second to last call to add returned a function. The function takes one argument. Putting a 100 after it added 30 to the 100.

(add 1) returns a function that takes one argument, and returns a value that’s one added to the argument.

(add 9) returns a function that takes one argument, and returns a value that’s 9 added to the argument.

Elm has some syntax that messes with the ordering, called a pipe. Here’s the pipe in action:

records
    |> map getCost
    |> filter (isOver 100)
    |> sum

records
    |> map getCost
    |> filter (isOver 100)
    |> sum

So, that makes sense. It’s like Unix pipes. Records piped into map getCost, piped into filter (isOver 100), piped into sum.

In English: all the costs from records, filtered to be over 100, and summed.

The pipe, |>, rearranges the way functions work. These two function calls are the same:

> add 1 2
3 : Int
> 2 |> add 1
3 : Int

What’s going on?

“2 |> add 1” means 2 passed to add 1. What is “add 1”?

(add 1) returns a function that takes a single argument, and adds 1 to it.

The following are all the same ((2 + 3) * (2 * 2)):

> mul (add 2 3) (mul 2 2)
20 : Int
> (mul 2 2) |> mul (add 2 3)
20 : Int
> (2 |> mul 2) |> mul (3 |> add 2)
20 : Int
> 2 |> mul 2 |> mul (3 |> add 2)
20 : Int

You can reformat the last one in the indented pipes layout:

2
    |> mul 2
    |> mul (3 |> add 2)

Yeah, it doesn’t make anything clearer, but you can try to work out how Elm evaluates the final value, and it will help clarify the pipe |>.

To show what I mean, I’ll highlight (in red) functions that can resolve to a function:

2
    |> mul 2
    |> mul (3 |> add 2)

Next, we pass values (on the left of the |>) into these functions, and they evaluate to values (in green).

4
    |> mul 5

That mul 5 will return a function:

4
    |> mul 5

Then, we pass 4 into the function returned by (mul 5) and evaluate.

20

Obviously, there are more appropriate places to use pipe notation, and this isn’t one of them.

This example below, however, is a good use of pipes.

records
    |> map getCost
    |> filter (isOver 100)
    |> sum

records
    |> map getCost
    |> filter (isOver 100)
    |> sum

That is the same as:

(sum (filter (isOver 100) (map getCost records)))

The post Learning Elm: pipe tricks first appeared on 🍙.

To get started, you need to install Elm. Then, you’ll get the elm command, which is like npm or composer. elm is a package manager and a build tool. Here’s part of the help when you type “elm”:

elm repl --help
elm init --help
elm reactor --help
elm make --help
elm install --help
elm bump --help
elm diff --help
elm publish --help

The main tools to use as a beginner are elm reactor, the web browser dev tool, and elm repl, the “console” where you can type Elm code and try it out.

I started with Array, List, and Maybe. Also see the syntax reference card and the core language reference.

It was a good way to get familiar with the notation:

fromList : List a -> Array a

The Array.fromList function takes a list as an argument, and returns an array.

push : a -> Array a -> Array a

The push function takes a value, and an array as arguments, and returns an array with the value appended to the end.

Arrays and Lists made sense, but Maybe was different. Type these lines into the REPL.

import Array exposing (..)

x = fromList [1, 2, 3]
get 1 x

-- returns Just 2 : Maybe number

The return value, Just 2, is not 2. You expect 2, but get Just 2. What is up with that?

Just 2 is of type Maybe. Maybe values can be “Just number” or “Nothing”. From the docs:

type Maybe a
    = Just a
    | Nothing

“Represent values that may or may not exist. It can be useful if you have a record field that is only filled in sometimes. Or if a function takes a value sometimes, but does not absolutely need it.”

So, this looked weird to me, but here’s a quick way to convert it to a normal value:

-- here's the function
withDefault : a -> Maybe a -> a

-- usage
withDefault 0 (Just 2)
-- returns the value 2 : number

OK, that is still weird. (Most languages have type coercion or functions to convert values.)

Here’s an example from the syntax guide:

<code>case maybeList of
    Just xs -> xs
    Nothing -> []</code>

This is a different way to coerce values. It switches based on the type variant of maybeList.

So Maybe is a type, with two variants “Just xs” and “Nothing“.

The case switching isn’t based on the value of the variable, but on the variant.

(This might look like a variant is, itself, a type. This isn’t the case, because maybeList must be a Maybe. The case switch will match only variants of Maybe. This is more restrictive than the case switch statements you see in OOP languages with a typeof() operator.)

I’ll stop at this point, because types are important to Elm. I have to spend more time studying it. It’s reminding me of types in Haskell: and that means it’s part of how the program executes.

https://dev.to/jigargosar/elm-vs-the-feature-addiction-epidemic-in-programming-ach

https://riptutorial.com/elm

https://guide.elm-lang.org/types

https://learnyouanelm.github.io/pages/03-types.html

https://www.elmcraft.org/

https://elmprogramming.com/

https://lamdera.com

https://github.com/sporto/awesome-elm

https://pragmaticstudio.com/tutorials/what-is-elm

https://www.sitepoint.com/functional-reactive-programming-elm-introduction/#google_vignette

https://en.wikibooks.org/wiki/Elm_programming_language

https://www.toptal.com/developers/front-end/getting-started-elm-language

https://dev.to/marciofrayze/why-is-elm-such-a-delightful-programming-language-2em8

https://github.com/elm

The post Learning Elm first appeared on 🍙.