Knuth's warning about premature optimization is really about not increasing complexity based on guesswork without profiling the actual bottleneck. That's about overall architecture design. What's happening here (in this blog post) is locally for the sake of learning, and further, for intellectual fun - I think it's completely justified.
Usually, the 'don't do premature optimization' quote gets misused as an excuse to avoid careful design, but setting that aside, learning within these kinds of constraints and eventually producing something.
that's not premature optimization in my view.
Looking at this code, they saved one AND instruction and reduced a pipeline stall, but it seems like it would be harder for a future maintainer to understand, because not_received feels a bit less readable. I always think
code that's easy for the computer to read and code that's easy for humans to understand are different things.
After writing my comment, I realized it came across as overly critical. But actually, I think this work is completely justified and beautiful. Honestly, it's at a level I couldn't achieve myself. I respect it.
Its like writing a thriller where you are the main operative, heroically saving the day with your skill, foresight and tenacity.
The problem is, it sets a rigid path far to early that you are unwilling to move away from, either because you had ambitions for those empty stubs, or because the obvious solution means admitting that you current $thing is not as successful as it should be.
The problem I have found recently is that it bleeds into the training set that LLMs to use to make software. our platform is pretty well defined and has excellent metrics and logging that come for free.
But the LLMs are creating Otel forwarders with custom NATs transport, even though we have all of that for free already (and in the agents.md)
Knuth's warning about premature optimization is really about not increasing complexity based on guesswork without profiling the actual bottleneck. That's about overall architecture design. What's happening here (in this blog post) is locally for the sake of learning, and further, for intellectual fun - I think it's completely justified. Usually, the 'don't do premature optimization' quote gets misused as an excuse to avoid careful design, but setting that aside, learning within these kinds of constraints and eventually producing something. that's not premature optimization in my view.
Looking at this code, they saved one AND instruction and reduced a pipeline stall, but it seems like it would be harder for a future maintainer to understand, because not_received feels a bit less readable. I always think code that's easy for the computer to read and code that's easy for humans to understand are different things.
After writing my comment, I realized it came across as overly critical. But actually, I think this work is completely justified and beautiful. Honestly, it's at a level I couldn't achieve myself. I respect it.
Oh of course its fun, its seductive.
Its like writing a thriller where you are the main operative, heroically saving the day with your skill, foresight and tenacity.
The problem is, it sets a rigid path far to early that you are unwilling to move away from, either because you had ambitions for those empty stubs, or because the obvious solution means admitting that you current $thing is not as successful as it should be.
The problem I have found recently is that it bleeds into the training set that LLMs to use to make software. our platform is pretty well defined and has excellent metrics and logging that come for free.
But the LLMs are creating Otel forwarders with custom NATs transport, even though we have all of that for free already (and in the agents.md)
Its fun when you are aware about what you are doing.
Yes and I usually say premature optimization is a skill.
Cries for IPv4-only structure in 2025!