Oh yes, I'd recommend everyone who uses the phrase reads the rest of the paper to see the kinds of optimisations that Knuth considers justified. For example, optimising memory accesses in quicksort.
This shows how hard it is to create a generalized and simple rule regarding programming. Context is everything and a lot is relative and subjective.
Tips like "don't try to write smart code" are often repeated but useless (not to mention that "smart" here means over-engineered or overly complex, not smart).
I dunno, Ive seen people try to violate "dont prematurely optimize" probably a thousand times (no exaggeration) and never ONCE seen this happen:
1. Somebody verifies with the users that speed is actually one of the most burning problems.
2. They profile the code and discover a bottleneck.
3. Somebody says "no, but we shouldnt fix that, that's premature optimization!"
Ive heard all sorts of people like OP moan that "this is why pieces of shit like slack are bloated and slow" (it isnt) when advocating skipping steps 1 and 2 though.
I dont think they misunderstand the rule, either, they just dont agree with it.
Did pike really have to specify explicitly that you have to identify that a problem is a problem before solving it?
>1. Somebody verifies with the users that speed is actually one of the most burning problems.
Sometimes this is too late.
C++98 introduce `std::set` and `std::map`. The public interface means that they are effectively constrained to being red-black trees, with poor cache locality and suboptimal lookup. It took until C++11 for `std::unordered_map` and `std::unordered_set`, which brought with them the adage that you should probably use them unless you know you want ordering. Now since C++23 we finally have `std::flat_set` and `std::flat_map`, with contiguous memory layouts. 25 years to half-solve an optimisation problem and naive developers will still be using the wrong thing.
As soon as the interface made contact with the public, the opportunity to follow Rob Pike's Rule 5 was lost. If you create something where you're expected to uphold a certain behaviour, you need to consider if the performance of data structures could be a functional constraint.
At this point, the rule becomes cyclical and nonsensical: it's not premature if it's the right time to do it. It's not optimisation if it's functional.
You've inadvertently made an argument for deprecation, not ignoring rob's rule.
When building interfaces you are bound to make mistakes which end users will end up depending on (not just regarding optimization).
The correct lesson to learn from this is not "just dont make mistakes" but to try and minimize migration costs to prevent these mistakes from getting tightly locked in and try to detect these mistakes earlier on in the design process with more coordinated experimentation.
C++ seems pretty bad at both. It's not unusual, either - migration and upgrade paths are often the most neglected part of a product.
> the opportunity to follow Rob Pike's Rule 5 was lost.
std::set/std::map got into trouble because they chose the algorithm first and then made the data model match. Rule 5 suggests choosing the right data model first, indicating that it is most important.
There's probably tons of stuff people use that is way slower than it needs to be but speed isn't one of their self-reported burning problems because they don't even realize it could be faster. pip vs uv?
To be fair, I think human nature is probably a bigger culprit here than the quote. Yes, it was one of the first things told to me as a new programmer. No, I don't think it influenced very heavily how I approach my work. It's just another small (probably reasonable) voice in the back of my head.
A state machine is a perfect example of a case where you would benefit from linear types.
Some things just need precise terminology so humans can communicate about them to humans without ambiguity. It doesn't mean they're inherently complex: the article provides simple definitions. It's the same for most engineering, science and language. One of the most valuable skills I've learned in my career is to differentiate between expressions, statements, items, etc. - how often have you heard that the hardest problem in software development is coordinating with other developers? If you learn proper terminology, you can say exactly what you mean. Simple language doesn't mean more clear.
I wasn't born knowing Rust, I had to learn it. So I'm always surprised by complaints about Rust being too complex directed at the many unremarkable people who have undergone this process without issues. What does it say, really? That you're not as good as them at learning things? In what other context do software people on the internet so freely share self-doubt?
I also wonder about their career plans for the future. LLMs are already capable of understanding these concepts. The tide is rising.
On top this my own language is Englishifying so it’s understandable it gets confused. But still, the whole thing is infuriating when you type something correct and boom, it becomes a word in another language.
>You see, the shapes of roads in real life come from an underlying essential fact: the wheel axles of a vehicle. No matter how you drive a car, the distance between the left and right wheels remains constant. You can notice this in tyre tracks in snow or sand. Two perfectly parallel paths, always the same distance apart maintaining a consistent curved shape.
Emphasis mine - that's not really true
- Cars have differentials, so the wheel speed can differ between wheels
- Steering geometry isn't parallel! The tyres turn a different amount when you turn the wheel
- Unless you're going in a straight line, cars don't go where the tyres point! Tyres 'pull' the car towards their slip angle
What you will actually see in tracks in snow or sand is non-parallel tracks, describing curves of different radii. You can also see this in racetracks, where the path more closely resembles the limits of car physics without care for passenger comfort or tyre wear. The example 'fail' image looks not dissimilar from a hairpin turn.
Author here: i agree the article oversimplified here and in practice vehicle tracks can sometimes be non concentric. But it has nothing to do with differentials. Differentials just allow wheels to rotate at different speeds (as perimeter of a smaller radius circle is smaller the outer one). Non parallelism usually comes from the Ackerman steering or slipping. But rear tracks of a vehicle going slowly through sand will always be concentric. Parallelism is important for engineers because it also allows multiple vehicles to go in parallel on a multi lane road. You can see how that is failing with bezier paths in the CS2 ss in the article. Also hairpin turns are usually designed with arcs in mind as well
> Do they have ABS sensors that can detect wheel lockup/speed status? Because I don't.
You should fix that. Go out on a rainy day and slam the brakes hard enough for it to kick in. There's an obvious vibration and knowing what it feels like might save your life.
I have the desktop app open right now. In the top-right corner is a nag saying 'Share your plan'. It's an ad for Proton Duo.
I just clicked 'Don't show again'. I get a toast saying you won't show me that offer again and it's immediately replaced with a nag saying 'Refer friends'. It has its own 'Don't show again'.
In August 2024 I sent Proton support an email with this text:
>I pay 95.88 € a year for Proton and every time I open the webapp or the desktop program, I see this:
The support reply told me I can remove the button by clicking on it, then "Don't show again". If I was frustrated enough to email you about it, I'm guessing I clicked it.
I have expressly opted out of ads for Proton Duo. You're interpreting this as me opting out of a single ad for Proton Duo. Changing the copy doesn't mean I have opted into comms about it. So I disagree you take this seriously.
Oh yes, I'd recommend everyone who uses the phrase reads the rest of the paper to see the kinds of optimisations that Knuth considers justified. For example, optimising memory accesses in quicksort.
reply