illuminator83

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 ...

Luckily it's not about that!

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.

So in that regard, not much has changed.

I and everybody else here call BS on that. People make mistakes all the time. Arguably at similar or worse rates.

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

Especially since the US is not going to have any allies anymore soon.

I'm a big fan of high-level languages and abstractions. I'm just not a fan of bad abstractions.

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.

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.

Let me do some quick research:

https://gist.github.com/bobrik/82e5722261920c9f23d9402b88a0b... https://nvd.nist.gov/vuln/detail/cve-2024-26923

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 do not know the guy, and I do not care who he is. This really is not "slop". I can attest to the validity of almost all of his points based on my own career. And even if he used ChatGPT assistance to help with the writing, the content clearly was not invented by ChatGPT. This is valuable advice for people in our industry.

For the most part, yes. Because people usually read docs and test it on their own.

But I remember a few people long ago telling me confidently how to do this or that in e.g. "git" only to find out during testing that it didn't quite work like that. Or telling me about how some subsystem could be tested. When it didn't work like that at all. Because they operated from memory instead of checking. Or confused one tool/system for another.

LLMs can and should verify their assumptions too. The blog article is about that. That should keep most hallucinations and mistakes people make from doing any real harm.

If you let an LLM do that it won't be much of a problem either. I usually link an LLM to an online source for an API I want to use or tell it just look it up so it is less likely to make such mistakes. It helps.

Yeah, for the most part. But I've even had a few instance in which someone was very sure about something and still wrong. Usually not about APIs but rather about stuff that is more work to verify or not quite as timeless. Cache optimization issue or suitability of certain algorithms for some problems even. The world is changing a lot and sometimes people don't notice and stick to stuff that was state-of-the-art a decade ago.

But I think the point of the article is that you should have measure in place which make hallucinations not matter because it will be noticed in CI and tests.

Are you sure? I've been confidently wrong about stuff before. Embarrassing, but it happens.. And I've been working with many people who are sometimes wrong about stuff too. With LLMs you call that "hallucinating" and with people we just call it "lapse in memory", "error in judgment", or "being distracted", or plain "a mistake".

It's the tragedy of the commons all over again. You can see it in action everywhere people or communities should cooperate for the common good but don’t. Because many either fear being taken advantage of or quietly try to exploit the situation for their own gain.

About 7 or 8 years ago I worked at a startup which got money from Softbank / Masayoshi Son. Our founder and our CTO went to meet him in LA IIRC to pitch.

They came back telling us he was basically asleep during the pitch meeting which was scheduled for only 10 minutes anyway.

Our business/product really had no chance of succeeding at this point and most knew it. We got some money from Softbank anyway - forgot how much. Our management was basically laughing about how easy it was to get funding from Softbank.

I jumped ship a year later or so and that was good timing.

I think in most of my projects, many of the C++ packages I used for work (lots of computer vision, video codecs etc) I had to compile and host myself. The latest and greatest of OpenCV, dlib or e.g. gstreamer weren't available on the distros I was using (Ubuntu, Fedora, Centos). They'd lag a year or more behind sometimes. Some stuff was outright not available at all via package manager - in any version.

So, yes, you do have to figure out how to build and package these things by yourself very often. There are also no "leftpad" or similar packages in C. If you don't want to write something yourself.

In constrast - virtually every software package of any version is available to you in cargo or npm.

I think it's mostly the fact that C dependencies are much rarer and much harder to add and maintain.

The average C project has at most a handful of other C dependencies. The average Rust, Go or NodeJS project? A couple hundred.

Ironically, because dependency management is so easy in modern languages, people started adding a lot of dependencies everywhere. Need a leftpad? Just add one line in some yaml file or an "Alt-Enter" in an IDE. Done.

In C? That is a lot more work. If you do that, you do it for advanced for stuff you absolutely need for your project. Because it is not easy. In all likelihood you write that stuff yourself.

Also pretty sure it is a feature because the general population wants to have pleasant interactions with their ChatGPT and OpenAI's user feedback research will have told them this helps. I know some non-developer type people which mostly talk to ChatGPT about stuff like

- how to cope with the sadness of losing their cat

- ranting about the annoying habits of their friends

- finding all the nice places to eat in a city

etc.

They do not want that "robot" personality and they are the majority.

I'm assuming "High Availability" is what is really meant here.

When you are commenting your schema, that's true. Anything which is generated by machines doesn't need comments either. But when it's written by people? And the values? That belongs with the 'payload'.

The wealth gap widening is quite independent from AI being involved. A natural progression which was always happening and continues to be happening. Entil some sort of catastrophe reshuffles the cards. Usually a war or revolution. The poor simply rising up or a lazy and corrupt ruling class depriving their country of enough resources and will to defend itself that some outside power can take it.

Everytime you push commits to a PR you decide what you push exactly.

The first time you push, you should have squashed/rebased your changes into a structure that make sense. Atomic commits are best. Could even be a single commit. Sometimes it makes sense to have multiple commits. E.g. - introducing a new API - moving other code to use the new API - deleting the old API

This could also be a single commit. That is really up to you/your team.

And yes, you rebase/squash and force push new commits. Every team I had in the past 12 years routinely used force-push for PR iterations.

Turns out, when writing production code, other people rarely checkout and work simultaneously on branches of half-finished stuff of other people. It is and should be very, very rare. Very occasionally it happens that someone bases their work on the branch another developer. In these cases, people just carefully rebase their branch on "origin/other-branch" after a fetch. You can't rely on people not force push anyway. Even if you agreed on it, sometimes this needs to be done. (e.g. commit a very large binary file by accident). So you need work in a way which assumes that somebody might have force-pushed their private branch.

Multiple people working on the same branch without a PR process is indeed messy and you should never force push when you do that. They key here is to avoid working with multiple people on the same branch in the first place. I've seen this happening only when: - Work items are too big and not broken down enough (branches are actively developed for for several weeks/months ). Usually and indication of lack of architecture and product leadership. If you do this, you have lots of other interesting problems as well. You are prototyping really but pretending you don't. - You are consciously experimenting and prototyping. Make whatever mess you want - in code and history. You are going to iterate so much and so messy that whatever you produce can't a product. Figure out what you want and need to do and start with a clean implementation afterwards. And maybe delete that messy branch eventually.

So, we have two modes: - Prototyping - which means you are allowed to make a mess because you throw it away anyway. No one, including you, cares much what you code and your repo history looks like. - Production - you write code and repo history for eternity. You do it right for the sake of everybody's sanity.

Well, he can start citing Martin Fowler or Bertrand Meyer. Then what?

Arguments from authority lead no where here. Because these "authorities" also disagree.

I always tell my engineers to create atomic commits and we usually review commit by commit. Obviously commits like "fixed review comments" or "removed some left-over comments" or "fixed typo" should not be pushed into a PR you asked others to review. I expect people to understand how to clean their commit history - if they don't I teach them. The senior people who are capable of structured work - e.g. are used to contribute open source projects - do it anyway. Because messiness is usually not tolerated by maintainers of important projects.

You find people how aren't able to craft clean commits and PRs usually thrive in environments in which people are either work mostly alone or in which cooperation is enforced by external circumstances (like being in the same team in a company). As soon as developers many are free to choose whom to associate with and whose code they accept - rules are usually made and enforced.

Oh, they were not talking about the implementation of these things. Just the the user side:

printf("Error: File `%s` in batch %d failed.", file.c_str(), batch) vs fmt::print("Error: File `{}` in batch {} failed.", file, batch)

One of which is objectively safer and more portable than the other. They didn't care. "I like what I've been doing for the last 20 years already better because it looks better.". "No Its not because I'm just used to it." "If you are careful it is just as safe. But you gotta know what you are doing."

And best of all - classic elitism:

"If you are not smart enough to do it right with printf, maybe you shouldn't be a C++ programmer. Go write C# or something instead."

The same person was not smart enough to do it right in many places as I've proven with a static analyzer.

Actually, developers are idiots. Everyone is. Some just don't know it or won't admit it.

I once joined a company with a large C/C++ codebase. There I worked with some genuinely expert developers - people who were undeniably smart and deeply experienced. I'm not exaggerating and mean it.

But when I enabled the compiler warnings (which annoyed them) they had disabled and ran a static analyzer over the codebase for the first time, hundreds of classic C bugs popped up: memory leaks, potential heap corruptions, out-of-bounds array accesses, you name it.

And yet, these same people pushed back when I introduced things like libfmt to replace printf, or suggested unique_ptr and vector instead of new and malloc.

I kept hearing:

"People just need to be disciplined allocations. std::unique_ptr has bad performance" "My implementation is more optimized than some std algorithm." "This printf is more readable than that libfmt stuff." etc.

The fact is, developers, especially the smart ones probably, need to be prevented from making avoidable mistakes. You're building software that processes medical data. Or steers a car. Your promise to "pay attention" and "be careful" cannot be the safeguard against catastrophe.

malloc and free aren't overhead.

If I'm reading a file, then opening and closing a file is not overhead either. But if I'm reading a file and some convoluted system in my own process is slapping some 3000% extra work on top because it needs to asynchronously track opened files and close them at arbitrary time later - that is overhead and creates bugs.

Which is one reason why many GC languages end up with bad emulations of an almost overhead free pattern like "try-with-resources" in Java and "IDisposable" in C# etc.