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 (more or less) 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.

Oh one other thing: the "fuzzer" component itself is not fully deterministic. It can't be, because it also has to forward arbitrary user input into the simulation component (which is deterministic). If you decide to rewind to some moment and run a shell command, that's an input which can't be recovered from a fixed random seed. So in practice we explicitly store all the inputs that were fed in.

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!

But it doesn't matter because the whole article is AI generated.

Nevermind Claude, does that mean Anthropic's offices can't use a power company if that same company happens to supply electricity to a US military base? What about the water, garbage disposal, janitorial services? Fedex? Credit card payments? Insurance companies? Law firms? All the normal boring stuff Anthropic needs that any other business needs.

This is a corporate death penalty. Or corporate internal exile or something, I don't know of a good analogy.

I do think you can get colour fringes in some circumstances. Try doing it in a dark room with a bright light coming through a small gap (e.g. between curtains). Like:

                                |
                                |                    (dark room)
                                |

    light source - - - - - ->- - - - - - - - - ->- - - - - - ->- - - - - - - - - ->  eye
                                                                       |
                                |                                      |
                                |                                      |
                                |                                    finger
                        small-ish gap (1-5cm)

IIRC you can get colour fringes between the finger and the top edge of the gap behind it.

EDIT: I just tested it, there is definitely a rainbow spectrum between the finger and the gap. The gap side is blue and the finger side is red. Not sure if this is the same effect as the article though.