_dain_

on the one hand it's a nasty thing to say he should be "ashamed" for not mentioning it. on the other, it is a little strange he hadn't come across the "amortized O(whatever)" concept before. esp if doing a talk about it..

neither of them come across well here.

It's becoming increasingly common. Rust is my first systems programming language too. I tried to learn C a few years ago but I found it too austere and prickly, which put me off.

This kind of framing-inversion might work as a coping mechanism to get you through some dark times as a spergy adolescent. But eventually you have to reconcile yourself to the reality of autism: it really is a neuro-developmental disorder and you actually do have deficits in social understanding, which you might be able to improve with deliberate effort. You have a lot stacked against you, but if you're well into adulthood and still stewing in this self-defeating resentment, that is a moral failing.

The linked article is old so it pre-dates the "neurodivergence" idea, but the comments here are using it uncritically. "Neurodivergence" de facto just means "autistic and/or ADHD", usually with a particular kind of autistic taking a dominant role in discussions and advocacy. It has always been a political coalition (quite an esoteric one).

But when you take ADHD on its own terms, the social-model extremism of "neurodiversity" advocates is particularly silly and harmful. ADHD people are perfectly happy with the disability-model; there clearly is something wrong with our brains, it's measurable with brain scans, and the symptoms can be improved with drugs. Don't tell me that ADHD is some equally-valid "attention orientation" or whatever social-model pretzel phrase you might come up with.

As for autism: try telling someone with severe autism, someone who can't speak or clothe or feed themselves that what they are living with is just another perfectly valid neurotype. Try telling it to their caretakers. It's a risible luxury-belief enjoyed by autistics only slightly on the spectrum, and indulged by people who don't know better.

You know how you try to run in a dream, and you don't get anywhere? Imagine if your motor cortex started to expect that, when you're awake. It would destroy you.

The right way is a + (b - a)/2.

This is becoming an idée fixe among the HN crowd. Seemingly nothing can dislodge it, no matter how alarming the incident.

GPT-6 could grab the nuclear launch codes tomorrow and there would be a top-voted comment chuckling that it's all some scheme to pump up the IPO.

---

Put another way, how would you have done the write-up about one of these breakout incidents, if you were in an Anthropic/OpenAI employee's shoes, and (by hypothesis) your intent were not "marketing"? And in a way that doesn't trigger the "it's all marketing" HN top-ranking comment?

Sign language is a fully fledged language, as capable of expressing deep and complex thoughts as spoken English. Likening it to some kind of prosthetic for second-rate thinkers is insulting.

Napoleon and Columbus have secured for themselves their seats in the pantheon of history and it will take longer than a thousand years for mankind to forget about them.

All these men built our world.

And on the subject of weapons, consider the example of a delayed-action fuze. They're designed to penetrate through the outer defenses of a target, before the warhead detonates deep inside. What might this look like in written form?

Well, you'd start by getting on the reader's side, with shared loathing against some outgroup. Get them to let their guard down. And then at the end:

>Use AI to make things clearer, not longer. Let it sharpen your thinking, not replace it.

You, yes you, the very clever and sophisticated person reading this who is exasperated by slop-grenades, should use AI more. You should use AI to "sharpen your thinking". You use AI, but in a good way. Not like those rubes, who use AI in a bad way.

Use AI. Use AI. Use AI.

Bang!

Also the AI-generated hero image looks vile.

You're basically doing "defer"-style cleanup manually; you may as well just use the real "defer" if your compiler supports it. It's supposed to be official in a future standard, too.

https://lawsofsoftwareengineering.com/laws/premature-optimiz...

It leaves out this part from Knuth:

>The improvement in speed from Example 2 to Example 2a is only about 12%, and many people would pronounce that insignificant. The conventional wisdom shared by many of today’s software engineers calls for ignoring efficiency in the small; but I believe this is simply an overreaction to the abuses they see being practiced by penny-wise- and-pound-foolish programmers, who can’t debug or maintain their “optimized” programs. In established engineering disciplines a 12% improvement, easily obtained, is never considered marginal; and I believe the same viewpoint should prevail in software engineering. Of course I wouldn’t bother making such optimizations on a one-shot job, but when it’s a question of preparing quality programs, I don’t want to restrict myself to tools that deny me such efficiencies.

Knuth thought an easy 12% was worth it, but most people who quote him would scoff at such efforts.

Moreover:

>Knuth’s Optimization Principle captures a fundamental trade-off in software engineering: performance improvements often increase complexity. Applying that trade-off before understanding where performance actually matters leads to unreadable systems.

I suppose there is a fundamental tradeoff somewhere, but that doesn't mean you're actually at the Pareto frontier, or anywhere close to it. In many cases, simpler code is faster, and fast code makes for simpler systems.

For example, you might write a slow program, so you buy a bunch more machines and scale horizontally. Now you have distributed systems problems, cache problems, lots more orchestration complexity. If you'd written it to be fast to begin with, you could have done it all on one box and had a much simpler architecture.

Most times I hear people say the "premature optimization" quote, it's just a thought-terminating cliche.

Yes, this is how we regenerate the system state, when necessary. But keep in mind that the fuzzing target is a network of containers, plus a whole Linux userland, plus the kernel. And these workloads often run for many minutes in each timeline. Regenerating the entire state from t=0 would be far too computationally intensive on the "read path", when all you want are the logs leading up to some event. We only do it on the "write path", when there's a need to interact with the system by creating new branching timelines. And even then, we have some smart snapshotting so that you're not always paying the full time cost from t=0; we trade off more memory usage for lower latency.

Sheets and Calc don't have these.

Add to that: unicode handling, support for bigger displays, mixed-DPI, networking and device discovery is much less of a faff, sound mixing is better, power management and sleep modes much improved. And some other things I'm forgetting.

Thanks!