They did not misunderstand anything. All of the behaviour is not inherent in raw base model and has been planted by the agressive, secretive reinforcement learning they do for benchmaxxing, "safety" and all other things. Claude begins any other sentence with "honestly". That is not how LLMs work, that is how they work after being RLed to the brink.
Before everyone piles on this comment with "whoosh" and "it was sarcasm" and such — have you noticed that reacting to ironic, sarcastic comments as if they were meant literally is what real LVL 80 trolls do oftener and oftener? On internet, you can never know who is pulling leg...
I have been carefully following the following personal rule:
Never edit or comment or contribute to stack overflow or english wikipedia or linux kernel.
It kind of feels like being non-smoker and reading about issues people who smoke have. Only the damage wikipedia causes appears to be much more random and severe.
I understand not all other language wikipedias are like the english one, but it's not worth the risk to your mind.
The addiction research has terms like LDWs and near-misses. It is massively researched topic. Even cursory reading helps to understand why table saw makes really bad slot machine. Really bad 3d printer? Maaaybe. But LLMs are, either by intelligent design or coincidence of worst outcomes, excellent slot machines! They almost succeed, produce small payouts, create suspense and anticipation, and their operation is unpredictable. Table saws have a long way to go
C is about the safest language you can choose, between cbmc, frama-c and coccinelle there is hardly another language with comparable tooling for writing actually safe software, that you can actually securely run on single-core hardened systems. I would be really interested to hear the alternatives, though!
do you know of a mitm proxy that "just works"? meaning, is able to spoof/intercept/modify running processes well enough that most stuff would run without manual modification?
"Prevent exceptions from leaving destructors." — thank you for providing well known sources that support my point! Although sadly we all have to eat Sutter Meyers bread, at least it explicitly tells you to not worry about the way exceptions are handled during object destruction — by simply avoiding such exceptions.
No C++ "bread and butter" I have seen so far goes into depth on this subject.
What book covers in depth *throwing* from destructors? Even more sane thing — throwing from constructors and function arguments — is mentioned in passing ("unwind will take care of everything, don't think too hard about it") unless you are in a language lawyer mailing list. But exceptions *during destruction*? What book discusses that? That's like covering use of NaN values as map<> keys...
If you noticed, the article did not actually tell you what happens when destructor throws. It was only about double-exception case and throwing in nothrow() function (both perfectly valid things to know when jobbing).
What state are members left in when destructor throws? If exception happens in virtual base? If member destructor throws, what other class members have they destructor executed? will delete[] be called?
The author possibly does not care to know themselves! As you say, totally irrelevant to any normal programming. Unless you are writing clang or gdb
this is always overlooked. AI stories sound like "with right attitude, you too can win 10M $ in lottery, like this man just did"
Running LLM on 1000 functions produces 10000 reports (these numbers are accurate because I just generated them) — of course only the lottery winners who pulled the actually correct report from the bag will write an article in Evening Post
If lossy-compressed transcodes of ripped movies are not "transformative works" and can get people even jailed, then lossy-compressed text of ripped books and websites is neither.
There is a lot of knowhow going into a good divx rip too, you know.
And it enables so much novel uses such as popcorn time, with fluorishing business opportunities.
Nothing gives programmer bigger sense of future job security than trying vibe-coding with a "frontierest" model and looking at the code. Especially once it starts changing existing code. Ah. And the fake tests. And those grandiose coments. Oh. It is quite marvellous.
I just wonder if companies will just instantly fold and sink once their internal slop pressure causes hull breach, or will they call slopbusters.
Sorry, I tought you meant "support infrastructure" in a much wider sense — yeah, LLMs are frighteningly good at lockpicking tests using source code shaped inputs. It's just that they are also frighteningly good at finding insane ways to game the tests, too. I wouldn't say that LLMs are very "G" in the AI they do — present them with confusing semantics, and they fall off the self-contradiction cliff. No capability of developing theory systematically from observations.