Earlier quoted context omitted.
The use of LLMs will lead to homogeneous, middling code.
I'm not sure if that's a criticism or praise - I mean, most people strive for readable code.
LLM generated code reminds me of perl's "write-only" reputation.
Using go fix to modernize Go code
11–20 of 97 posts
Re: Using go fix to modernize Go code
#12I really liked this part: In December 2024, during the frenzied adoption of LLM coding assistants, we became aware that such tools tended—unsurprisingly—to produce Go code in a style similar to the mass of Go code used during training, even when there were newer, better ways to express the same idea. Less obviously, the same tools often refused to use the newer ways even when directed to do so in general terms such a…
I definitely see that with C++ code
Not so easy to "fix", though. Or so I think. But I do hope still, as more and more "modern" C++ code gets published
Re: Using go fix to modernize Go code
#13I really liked this part: In December 2024, during the frenzied adoption of LLM coding assistants, we became aware that such tools tended—unsurprisingly—to produce Go code in a style similar to the mass of Go code used during training, even when there were newer, better ways to express the same idea. Less obviously, the same tools often refused to use the newer ways even when directed to do so in general terms such a…
The use of LLMs will lead to homogeneous, middling code.
It does. I’ve been writing Go for long enough, and the code that LLMs output is pretty average. It’s what I would expect a mid level engineer to produce. I still write code manually for stuff I care about or where code structure matters.
Maybe the best way is to do the scaffolding yourself and use LLMs to fill the blanks. That may lead to better structured code, but it doesn’t resolve the problem described above where it generates suboptimal or outdated code. Code is a form of communication and I think good code requires an understanding of how to communicate ideas clearly. LLMs have no concept of that, it’s just gluing tokens together. They litter code with useless comments while leaving the parts that need them most without.
Re: Using go fix to modernize Go code
#14Earlier quoted context omitted.
I'm not sure if that's a criticism or praise - I mean, most people strive for readable code.
LLM generated code reminds me of perl's "write-only" reputation.
In all honesty I've only used LLMs in anger with Go, and come away (generally speaking) happy with what it produced.
Re: Using go fix to modernize Go code
#15I really liked this part: In December 2024, during the frenzied adoption of LLM coding assistants, we became aware that such tools tended—unsurprisingly—to produce Go code in a style similar to the mass of Go code used during training, even when there were newer, better ways to express the same idea. Less obviously, the same tools often refused to use the newer ways even when directed to do so in general terms such a…
The use of LLMs will lead to homogeneous, middling code.
[dead]
Re: Using go fix to modernize Go code
#16Earlier quoted context omitted.
I'm not sure if that's a criticism or praise - I mean, most people strive for readable code.
LLM generated code reminds me of perl's "write-only" reputation.
Does it really? Because I see some quite fine code. The problem is assumptions, or missing side effects when the code is used, or getting stuck in a bad approach "loop" - but not code quality per se.
Re: Using go fix to modernize Go code
#17I really liked this part: In December 2024, during the frenzied adoption of LLM coding assistants, we became aware that such tools tended—unsurprisingly—to produce Go code in a style similar to the mass of Go code used during training, even when there were newer, better ways to express the same idea. Less obviously, the same tools often refused to use the newer ways even when directed to do so in general terms such a…
The use of LLMs will lead to homogeneous, middling code.
You might even say that LLMs are not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.
Re: Using go fix to modernize Go code
#18I really liked this part: In December 2024, during the frenzied adoption of LLM coding assistants, we became aware that such tools tended—unsurprisingly—to produce Go code in a style similar to the mass of Go code used during training, even when there were newer, better ways to express the same idea. Less obviously, the same tools often refused to use the newer ways even when directed to do so in general terms such a…
They're particularly bad about concurrent go code, in my experience - it's almost always tutorial-like stuff, over-simplified and missing error and edge case handling to the point that it's downright dangerous to use... but it routinely slips past review because it seems simple and simple is correct, right? Go concurrency is so easy!
And then you point out issues in a review, so the author feeds it back into an LLM, and code that looks like it handles that case gets added... while also introducing a subtle data race and a rare deadlock.
Very nearly every single time. On all models.
Re: Using go fix to modernize Go code
#19I really liked this part: In December 2024, during the frenzied adoption of LLM coding assistants, we became aware that such tools tended—unsurprisingly—to produce Go code in a style similar to the mass of Go code used during training, even when there were newer, better ways to express the same idea. Less obviously, the same tools often refused to use the newer ways even when directed to do so in general terms such a…
The use of LLMs will lead to homogeneous, middling code.
Do LLMs generate code similar to middling code of a given domain? Why not generate in a perfect language used only by cool and very handsome people, like Fortran, and then translate it to once the important stuff is done?
Re: Using go fix to modernize Go code
#20I really liked this part: In December 2024, during the frenzied adoption of LLM coding assistants, we became aware that such tools tended—unsurprisingly—to produce Go code in a style similar to the mass of Go code used during training, even when there were newer, better ways to express the same idea. Less obviously, the same tools often refused to use the newer ways even when directed to do so in general terms such a…
The use of LLMs will lead to homogeneous, middling code.
Middling code should not exist. Boilerplate code should not exist. For some reason we're suddenly accepting code-gen as SOP instead of building a layer of abstraction on top of the too-onerous layer we're currently building at. Prior generations of software development would see a too-onerous layer and build tools to abstract to a higher level, this generation seems stuck in an idea that we just need tooling to generate all that junk but can continue to work at this level.