Boeing and Airbus? I'm OK with that.

Well, we should certainly be able to distinguish between 'policy that has value for the community at large' and 'policy that supports a single stakeholder's objective (even when that's the stakeholder with the gold)'. So I don't disagree with you.

"When everyone is thinking alike, no one is thinking."
https://quoteinvestigator.com/...

See https://www.iso.org/standard/7... And for the history of COBOL language standardization, see the table here https://en.wikipedia.org/wiki/...

Programming languages managed buy ISO committees change slowly. That's a FEATURE. I worked a bit on the Ada standard. Each proposed change was carefully weighed for its impact on existing code, as well as the value for new code. The standard was updated roughly every 10 years.

Sorry I don't have moderator points for parent! +1 interesting

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