I've seen lots of code that people have maintained for 20 years and its full of these duplication and worse.
In fact I'm sad to say that majority of code I've seen people write and maintain is worse than what LLMs produce today.
Often it is inexperience, sometimes it is willful negligence, but most often it is just tight deadlines and pressure to do finish whatever is being done right now. People know how to do it better, but nobody got the time and budget to actually do it.
LLMs also learned from that.
I think a lot of people here have either not read the article fully or are misapprehending it.
Neither this author nor most other sane people I know claim that the code or architecture these "loops" produce is great. In fact, the author explains how it is not great.
His point is rather, that we'll increasingly see a world in which code quality and maintainability by humans will cease to matter for a lot of codebases.
There might be many software companies in the future which successfully sell software products which were created without a single software developer being involved in its development or maintenance. The code might be bloated and bad - but it doesn't matter because machines can still create and maintain it cheaper and faster than people can.
I already see this happening at a small scale at the place where I work. Product managers with zero coding ability are attempting to create entire new product features on their own using Claude or Codex. We do not let them merge this stuff unsupervised but in some corners and in new repositories they are publishing stuff that they have barely spoken about with a developer. They are just doing it. We'll see more of that.
Phew .... I saw the title and thought this was some horrid LinkedIn post from a "Founder" dad about teaching his kids how to pitch their startup to investors ...
Installation of software has usually become simple and easy enough that I feel more safe if i just look it up on the official source and run some curl or package manager command to get it installed. I trust that more than letting an LLM figure it out and then having to worry that I it got hijackeed and installs something based on out-dated or wrong info.
But configuring / setting up complex pieces of technology is something in which I let LLMs help me regularly. I'm happy that I don't have to RTFM that much anymore to get something done.
And yes, I'd hate to figure out IAM policies myself or decipher a truckload of error message of third-party systems by myself.
So, yes, I expect LLM help with these kind of things is going to become the norm.
For an LLM to work well, the installer should still exist, the UX should also be kind of self-explanatory and the error message must also have relevant and clear info.
Intelligent people tend to reproduce a lot less than other people. You wanna be average (or slightly above) for the best chance at successful procreation.
And hyper-intelligent people are especially bad at procreation.
It's not really about the implementation of Java (might be bad, I don't know).
It is the specification.
- People talked about null being an issues and that is a big one.
- The entire idea of OOP extremism Java implemented was a mistake - though just a consequence of the time it was born in. Much has been written about this topic by many people.
- Lacking facilities and really design for generic programming (also related to the OOP extremism and null issue
So much more more you can find out with Google or any LLM
I'm hoping for a future in which humankind looks back with embarrassment at this silly period in its history in which people used to think a leaky and bad abstractions like garbage collection was ever a good approach to deal with resource life-times.
I think we are just used to it. Like we are used to so many suboptimal solutions in our professional and personal lives.
I mean, look something like C++ or the name "std::vector" specifically. There are probably 4 Trillion LoC containing this code out there - in production. I'm used to it, doesn't make it good.
Monkey's paw: you get your wish, but so does someone who wants RAII and single-use-malloc to be left behind as a leaky and bad abstractions.
We all happily march into a future where only arena allocation is allowed, and when the arena is overfull it can only be fully reset without saving data. Copying still-used data out if it before reset is not allowed, as that's a copying half-space garbage collector. Reference counting is of course not allowed either as that's also garbage collection. Everyone is blessed...?
Some problems are just fundamentally easier to solve using cyclic data structures whose lifetime exceeds the scope where they were created, which would be quite difficult to clean up properly in any other way.
Indeed. I also hope we stop using all of these "high-level" languages. So much overhead just so people don't have to learn how to write proper optimized machine code. It's super-trivial to write a website directly in that too, and it only takes a bit longer, but it is almost twice as fast.
Did you know the Linux kernel has a tracing garbage collector in it, specifically for Unix socket handles? It seems to be a recurring solution to a common problem.
There are lots of suboptimal solutions for lots of problems out there. I don't know why it would matter if the Linux Kernel does the same mistake.
And I'm sure that wasn't the only solution. Just something somebody implemented and noone bothered to change it because it worked "well enough".
But I wouldn't be surprised if this is known to cause the kind of issue GCs are known to cause such as race conditions, resource exhaustion and stalling.
