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.
But Go culture promulgates this practice of repeating boilerplate. In fact this is one of the biggest confusion points of new gophers. "I want to do a thing that seems common enough, what library are you all using to do X?". Everyone scoffs, pushes up their glasses and says, "well actually, you should just use the standard library, it's always worked just fine for me". And the new gopher is confused because they really believe that reinventing the wheel is an acceptable practice. This is what leads to using LLMs to write all that code (admittedly, it's a fine use of an LLM).
LLMs have always been great at generating code that doesn't really mean anything - no architectural decisions, the same for "any" program. But only rarely does one see questions why we're needing to generating "meaningless" code in the first place.
This gets to one of my core fears around the last few years of software development. A lot of companies right now are saddling their codebases with pages and pages of code that does what they need it to do but of which they have no comprehension.
For a long time my motto around software development has been "optimize for maintainability" and I'm quite concerned that in a few years this habit is going to hit us like a truck in the same way the off-shoring craze did - a bunch of companies will start slowly dying off as their feature velocity slows to a crawl and a lot of products that were useful will be lost. It's not my problem, I know, but it's quite concerning.
The "LLMs shouldn't be writing code" take is starting to feel like the new "we should all just use No-Code."
We’ve been trying to "build a better layer" for thirty years. From Dreamweaver to Scratch to Bubble, the goal was always the same: hide the syntax so the "logic" can shine. But it turns out, the syntax wasn't the enemy—the abstraction ceiling was.
Where are the amazing no-hassle, no-boilerplate tools from last generation? Or the generation before that? Give me a break: it's easy to post this but it's proven very hard to simply "pick the right abstraction for everyone".
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.
I am also of the opinion that LLMs are still pretty bad at what's called "Low level design" - that is structuring functions and classes in a project. I wonder if a rule like torvalds' "No more than 4 levels of indentation" might make them work better.
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?
middling code, delivered within a tolerable time frame, budget, without taking excessive risk, is good enough for many real-world commercial software projects. homogeneous middling code, written by humans or extruded by machines, is arguably even a positive for the organisation: lots of organisations are more interested in delivery of software projects being predictable, or having a high bus-factor due to the fungibility of the folks (or machines) building and maintaining the code, rather than depending upon excellence.
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.
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.
Over the years there's been a couple of apps that have tried to use email protocols as the backend for chat. I really wish those had gained popularity - there's a lot of overlap with messaging and email.
Isn't that just email then? I mean I guess you could wrap a bubbly UI around it, but you're not getting around the latency and spam. Those seem like dealbreakers to me.
Latency isn’t that much of an issue. There might be greylisting for the initial message, but once the receiving server knows you, it’s pretty usable. And since everything is an email, you can “chat” with people that don’t use DeltaChat and they can reply using their normal email program. If you’re not using encryption, that is.
Having learned programming in the 80s (as a teen), I would say it was much easier back then. Programmers have made things vastly more complicated these days.
You don't have to use all the features of C#. I make my living at it and don't touch a lot of them. The issue with C# is culture. They went full in on blog driven development so there's way too many people who will yell this is the way to do things this week.
It's true. You will incur the wrath of C#'ers if your simple ToDo list app doesn't have a ToDoListItemRepositoryServiceFactory.cs and a minimum of 4 separate layers in which one must update 20 files because you added a property to one class.
Don't get me wrong, I still love C#/.NET. I use it everyday, but my god, has Swift been a breath of fresh air. The Swift community, when not whining about Swift UI, has been much less dogmatic in my experience.
reply