This is a fantastic discussion between John Ousterhout and Robert Martin on the issue of commenting code, but more of understanding code.

In brief: Robert “Bob” Martin aka “Uncle Bob”, author of “Clean Code”, could not explain an algorithm he published himself in his own book. He generally advocates to minimize comments, and published it without comments.

When asked by Ousterhout, he was also not able to change it without breaking it, because he did not understand the invariants in the code he published.

Bonus points for that he copied the algorithm - which is an efficient algirithm for finding prime numbers - from Don Knuth, who published it as an example for his lucid invention of “Literate Programming” - a method to better explain code and its pre-conditions and invariants, by interspersing explanatory text with the actual code, and providing a tool that extracts the program code from it.

Extra bonus points for that the algorithm which Don Knuth documented was first published by grandmaster Edsger W. Dijkstra in “Notes on Structured Programming”. A brilliant book chapter which explains once and for all invariants in code and data structures.

Both Don Knuth’s article on “Literate Programming" and Dijkstras book chapter in “Notes in Structured Programming” are available online, I can only encourage to take the time to read them - both of them are timeless masterpieces on writing computer programs.

(And also, Ousterhouts book “A Philosophy of Software Design” is a really good and nice book on modern software engineering - highly recommended.)

I was not dreaming about using numpy on the phone for doing compound interest calculations…

He sounds a bit depressed, yes.

It might be right that part of the software industry has just entered a downward spiral like a stalled jet. They could not make anything of value and quality and have commited to lower quality, less value, in a race to the earth surface.

Consumers don’t demand better quality because their expectations have reached zero. What these companies produce is worthless to them.

But there exist other areas where software delivers massive value and I think in two years or so, good developers which still know how to code and to maintain and debug old stuff, will be worth their weight in gold for such companies, because the sloppers won’t be up to the job.

Also, paradoxically, I think this will make companies to rely more on open source. In the last weeks I heard from two different companies that their suppliers - firms which were delivering stepper motors with firmware and such - are not any more able to make their stuff work. One company has resorted to do the testing for their supplier.

And there is a lot of software that needs to work. More than ever.

This is why companies are resentful towards software developers: They need them.

Comments rot. The code changes. The comment beside it doesn’t. By the third commit the prose lies about the line above it.

That only happens if people editing the code do not see comments as valuable and important. The fix is easy: Unterstand the code, its changes in the version log, and update and correct the comments as you change the code.

And: If LLM tools could really understand code, it would be easy for them to check changed code and point out where code and comments do not match any more - and why.

The worst, I think, is to have all three of specs and requirements, code, and comments and documentation generated by LLMs.

Because then you have nothing which is checked by a human whether any of it makes really sense.

If the LLM tool just implemented a signature/spec/architecture wrong that was written by a human, this would be easy to fix later, without messing up the interfaces within the system. Not so if you have ai Spaghetti code created without human understanding.

BTW… my impression is that “ai” tools (LLMs) are pretty shit at invariants. Invariants require understanding.

This is a fantastic discussion on the issue:

https://github.com/johnousterhout/aposd-vs-clean-code

In brief: Robert “Bob” Martin, author of “Clean Code”, could not explain an algorithm he published himself in his own book. He published it without comments.

He was also not able to change it without breaking it, because he did not understand the invariants in the code he published.

Bonus points for that he copied the algorithm from Don Knuth, who published it as an example for his lucid invention of “Literate Programming” - a method to better explain code and its pre-conditions and invariants, by interspersing explanatory text with the actual code.

Extra bonus points for that the algorithm which Don Knuth documented was first published by grandmaster Edsgar Dijkstra in “Notes on Structured Programming”. A brilliant book chapter which explains once and for all invariants in code and data structures.

Does that actually fit your experience?

Many LLM-generated projects are new and only a few months old. I would avoid such projects (regardless whether they declare ai usage or not). Most die quickly and end up unsupported.

For older and larger projects, the cadence and size of submissions should give a valuable hint. For any project that is larger than, say, 10,000 lines of code, a contributor will rarely submit more than 100 new lines of code per day, and very rarely more than 1,000 lines of changed code. Anything exceeding that is a strong hint that primarily LLMs are used.

This was already a major problem with social networks , gmail and so on - users think these authorize them to give away private data of you- like phone numbers, mail adresses, text message content, images - of you.

Now things that have been told in confidence only for their ears are added to that list.

This is also a major problem with social networks, gmail and so on - users think these authorize them to give away private data of you- like phone numbers, mail adresses, text message content, images - of you.

Now things that have been told in confidence only for their ears are added to that list.

I noticed that with self-checkout terminals, fruit varieties are still mis-labeled and missing. I noted that because I write down the price for such items, to be sure I enter the correct variety and price. It wasn’t there. Not only you’d pay more than is on the label - you also risk to be accused of theft if there is a bag ceck. And if you call somebody to correct it, you waste several minutes since the missing variety might not even be in the system.

The time saving is hugely illusory. You really should take your watch and measure. What costs most time at a staffed register checkout is mostly the payment. The staff scans much faster than you.

Try to save a file to “PRN”.

their point is that the bar for sending reports in should be as low as possible

Why?

Look: The bottleneck is not the number of reported possible issues, but the time, attention, and sustainable workload for the GNOME maintainers and developers. Anything that minimizes the latter is good.

Also, if LLM tools really continue to improve a lot (which is doubtful IMO), a shitty, half-assed, inconplete, ill-described bug report of today that is not attended to, due to its deficit, is not lost: If the bug is real and persists, due to the proclaimed future advancements in LLM technology, maintainers will receive another much much better bug report which causes less work in a year or two. Since maintainer’s work capacity is the real bottleneck, this is a clear win!

I think the AI companies are trolling FOSS projects with such inflammatory proposals. Be they “anti-AI” or “pro-AI”.

Remember before the last US election, disinformation targeted both parties to stifle more conflict. It is information warfare targeting FOSS because the tech bros and FANNG corporations do not want users with control over their software. Their relationship to FOSS is purely parasitic.

The antidote is to center projects in actual goals and values, set really clear boundaries based on these, communicate these excellently, friendly, and firmly, and ignore the remaining people (or just bots) which keep trolling.

If somebody wants to fork a project like GNOME and turbo-charge it with LLMs, let them prove they can do better and find users who want the slop.

turns out it’s also developed by a terrible person.

GNOME is developed by many people.

Not a dissertation, but here you go:

https://en.wikipedia.org/wiki/Wikipedia:Signs_of_AI_writing

… with many clear examples.

That would lead to an AI ice age. Surely not the worst development for Gaia and her children.

It honestly might have been a tool for wealth transfer this entire time.

Not unlike what happened with WWI. Propaganda, delusion, and enthusiasm played a key role then. Added by the then ruling classes’ greed, incompetence, stupidity, and utter irresponsibility. The result was misery for millions and a few people turned filthy rich.

I was really surprised that brave browser is mentioned in the Arch Wiki software list - without mentioning the adware.