Use boring languages with LLMs
1–10 of 180 posts
Re: Use boring languages with LLMs
#2Contradictory anecdote: there’s basically only one way to write Elm, as it is a very trend-resistant language with minimal updates over long timespans, but most agents in my experience will throw Haskell syntax and Prelude functions into their Elm output. Compiler or LSP will often set them right but they still try it initially
Re: Use boring languages with LLMs
#3Contradictory anecdote: there’s basically only one way to write Elm, as it is a very trend-resistant language with minimal updates over long timespans, but most agents in my experience will throw Haskell syntax and Prelude functions into their Elm output. Compiler or LSP will often set them right but they still try it initially
Interesting, I have a different experience.
I have worked extending the Elm compiler and both Opus 4.6, GPT 5.4 and GLM 5 had no issues both with the Elm compiler (written in Haskell) and my extended Elm.
I didn't see them hallucinate much, not more than on mainstream languages.
Re: Use boring languages with LLMs
#4Contradictory anecdote: there’s basically only one way to write Elm, as it is a very trend-resistant language with minimal updates over long timespans, but most agents in my experience will throw Haskell syntax and Prelude functions into their Elm output. Compiler or LSP will often set them right but they still try it initially
Interesting, what models are you using? My use with sonnet 4.6 has been a breeze for the most part
Re: Use boring languages with LLMs
#5Has Go become a "boring language"?
Re: Use boring languages with LLMs
#6> From a model’s standpoint, there are simply too many ways to write any of this
They seem quite good at figuring this out in my experience
Re: Use boring languages with LLMs
#7I haven’t had an issue using Python with LLMs where I have to decide “Should one use pip, poetry, or uv?” Since there is enough training data using pip or just choose that since it is the most boring solution and many of the commands map to uv since uv has a superset of features. Not that go is a bad solution honestly I would just say use what you know best.
Re: Use boring languages with LLMs
#8Has Go become a "boring language"?
The most non boring thing you can say about it is that it's terrible for ignoring most of what we've learned in the past couple decades of programming language design.
That generates plenty of excitement.
Re: Use boring languages with LLMs
#9Rather than "boring", this seems to be reaching for something like the concept of a "pit of success", or https://haskellforall.com/2016/04/worst-practices-should-be-... . I don't think the fact that the most common pitfalls in Go are well known should be taken as a sign that it doesn't have more esoteric pitfalls as well; it's just that the common cases (like nil) are the ones that everyone sees all the time.
Re: Use boring languages with LLMs
#10Has Go become a "boring language"?
It has been boring from the start.
It would be an interesting language, had it been released at the time of any of its influences, Oberon in 1987, Limbo in 1995.
Back when the type system ideas from CLU, Standard ML, Cedar were still taking off among industrial programming languages.