Elif

One more context where they genuinely conflict with the goal: performance-critical code.

Indirection has a runtime cost — virtual dispatch, allocation, cache behaviour. Usually irrelevant. In an inner loop, or in constrained embedded work, it is the difference between meeting a deadline and not.

That is a narrow exemption and it gets claimed far more often than it applies. But it is real, and in those places the readable design and the fast design genuinely diverge, which no amount of principle will resolve for you.

There is no flaw. Your argument is correct and it is a real theorem: no lossless compressor can shrink every input. For any compressor, some inputs must get longer.

The counting argument you gave is exactly the proof, and it is worth appreciating that you derived it yourself.

What you have not noticed is that this does not conflict with compression working, because real compressors do not claim to shrink everything. They shrink some inputs — a very particular subset — and expand the rest slightly.

And the subset they shrink is the one we care about. Text, images, audio, source code, logs, executables: all deeply patterned, all a vanishingly small fraction of the space of possible bit strings. Almost all bit strings are noise, almost none of them are ever stored in a file, and a compressor is a bet that its input comes from the patterned corner rather than from the enormous random middle.

So compression is not magic, it is exploitation of a bias in which files actually exist.

They are genuinely different, and the relationship is straightforward once stated: code expresses an algorithm.

An algorithm is a procedure — a finite sequence of unambiguous steps that takes an input and produces an output. It is an abstract object. It exists independently of any language and can be written in English, in pseudocode, on a whiteboard, or in your head.

Code is a concrete text in a particular programming language that a machine can execute. The same algorithm has many possible codings; two implementations in different languages are the same algorithm and different code.

So binary search is an algorithm. Your twelve lines implementing it are code.

The distinction matters when you are reasoning about correctness or complexity, because those are properties of the algorithm rather than of the text. It matters much less when you are describing what you spent your afternoon on.

One practical note whichever way you go: be consistent, and document it in one paragraph at the top of your API reference.

The worst outcome is not either convention. It is a service where some endpoints use status codes, some use the envelope, and a few use both with different meanings. Clients then need per-endpoint knowledge, which is exactly what an API is supposed to avoid.

The causes of corruption are worth listing, because they explain why it is a category rather than an anomaly.

• Memory faults. A cell that fails, or a bit that flips without failing permanently.
• Radiation. A charged particle striking a memory cell can flip a bit. At altitude this is measurably more frequent than at ground level, which is precisely why it appears in an aviation report and rarely in a discussion of web software.
• Marginal hardware — power supply excursions, timing violations, a connector that is nearly making contact.
• A different piece of software writing where it should not, which is a bug in that other software producing corruption in this one.

That last one shows the categories are not disjoint in origin, only in mechanism. What is investigated is which mechanism produced the observed behaviour, not who is ultimately at fault.

For anyone maintaining something and wondering when to do it: the practical trigger is when breaking your users starts costing more than keeping your freedom.

If three people use your library, breaking changes are a message in a chat. At three hundred, every breaking change is a day of support and a long tail of people stuck on an old version. Somewhere in between, committing to a contract becomes the cheaper option, and that is the moment for 1.0.0 regardless of how finished it feels.