Yes! Particularly in languages with rich semantics and a tradition of meaningful identifiers, the primary focus on documentation where I've worked has been on 'why' rather than 'what.' In Ada, which separates specification/API from implementation, the comments in the spec explained what the package did (including errors/exceptions), and the comments in the body concentrated on capturing what was not obvious -to a maintainer- in the code. Ada culture strongly emphasized maintainability, and that was emphasized in code reviews.

On one project, I ended up as "the first maintainer", having to rewrite a package that was widely used throughout the large application. I had to live with that specification, although I did add comments on errors that could be signaled by the various operations. But I rewrote that package body twice, the first time for time performance, and the second time to minimize space (it was a generic package. The compiler was unable, due to the complexity, to do 'code sharing' automatically, so I ended up using a lot of compiler specific dirty tricks to manually implement shared generics. And I documented all the tricks and knowledge about what I was doing in that package body. I also delivered a 'warranty' with that, telling my successor afterI left that job, "If you get a bug report, contact me and I'll work with you to fix it." She never called, and about 10 years later we connected, and I asked: "Any bugs on that code?" "No, it worked perfectly.")

For me, it was a Xerox XDS (formerly SDS) Sigma 7... And I learned a lot about programming from studying the BASIC source code of that application. I got yelled at by one of the university's system programmers when I asked her a question "why did they do it this way?" Then she answered my question.

I didn't know it's now -Sir- Idris. Good on him!

And I don't have any long range commitments for the next couple of years... And with a bit of coaching, I could pull of an appropriate accent.

On a system safety telecon, I totally lost it because someone said "Why would anyone have the network be safety-critical?" on a networked combat system. The contractor wanted to fire me, or at least get me moved off the program. I told my government boss, "Well, if I'm going to get fired, getting fired for being overly aggressive on soldier safety is something I'm OK with...."

How will he react? Will he conduct a DOGE purge of AI agents? Will there be a 'morality test' and any AI that fails this is sent to the "Gulag Cloud"? Will he fire the Marxist developers who obviously coded "woke AI"? Also, I'm sure the late night comedians will have a lot of fun with this, too.

Security liability should apply across the supply chain. But if you're ok with blaming God for mistakes made by incompetent developers, that's I guess your religious freedom at work...

I repeat my call for legal liability for companies that sell products or services with errors, including security vulnerabilities.

hmmm... Providing a link to something not yet published is questionable (at least without mentioning that.) But having the link point to the -wrong- page is just bogus.

The post itself has an error. The last link's URL points to the same page as the predecessor. There is no record for 43500

How do we find both Musk and Altman guilty, and sentence them to life in prison?

I think the 'usual suspects' lock on enterprises is MUCH weaker than it has been. Look at all the people carrying corporate issued or at least corporate approved iPhones and Macs. And the Neo punctures a lot of the acquisition cost arguments, for a lot of people (secretaries, sales people, managers), a Neo would be just fine.. (Getting through to the life-cycle costs is a harder proposition, mostly because of sunk costs in personnel. No CIO wants to reduce his/her headcount, that's a primary driver of budget and authority. Similarly, moving to longer replacement cycles because of hardware quality would also impinge on CIO budgets.)

For consumer networking, there are LOTS of choices, sure. But the -quality- of those choices is highly questionable, and chief among those quality attributes is 'security'. (I did try an Eero, couldn't get it to work as expected. But I have neighbors who are happy with their Eeros.)

I'd like to see Apple get back into the networking/router business. The only reason I gave up my old Airport Extreme was problems with buffer bloat on a slower ISP connection. Tim Cook would talk about "owning the critical parts of the infrastructure", and it seems to me that WiFi counts.

I replaced that Airport with an Ubiquiti Dream Machine about 5 years ago. The unboxing of that Dream Machine was a direct rip-off of the Apple Airport Extreme. The initial configuration of that was painful (even with a friend who had one at his house helping me.) Over the years, the Ubiquiti software has matured. It's still more complex than the Airport Utility, but that complexity is generally well managed. Apple could do worse than buy Ubiquiti, methinks...

I remember Java for years had a license restriction against using it for safety-critical applications.

It's interesting to consider restrictive licenses as a legal liability measure (as I suspect was true for Java), versus a technical or moral measure (i.e. 'we don't trust this well enough to use in some circumstances.')

But I wonder if the FSF position will change if/when AI vibe-codes non-open-license replacements for key OSS projects.... Would they claim that the LLM 'inhaling' GPL licensed software inherits the license terms of the input?

Only those with Need to Know/Read into the program will know the details, beyond what's being reported. So lots of Goole employees who might object to this will remain ignorant of what management is actually up to.

I suspect a lot here see that as a significant problem. (But in the grand scheme of things, I'm not losing sleep over this one.)