alt Hacker NewsRob Pike’s Rules of Programming (1989)
Comments
Meta: Love the simplicity of the page, no bullshit.
Funny handwritten html artifact though:
<title> <h1>Rob Pike's 5 Rules of Programming</h1> </title>Can you actually follow rule #1 for things like realtime audio programming?
> "Premature optimization is the root of all evil."
This Axiom has caused far and away more damage to software development than the premature optimization ever will.
See Tony Hoare:
This resonates as true, as long as the fundamentals of your tools are there. Picking interpreted languages or browsers as targets shoots you in the foot and sets you magnitudes behind when performance starts to matter. But if you're using a native-compiled language with value- and move-semantics, immutable data, and a composable type system, it's shocking how easy it can be to write obvious, maintainable, fast programs that perform under pressure, even when you're not being clever.
Thankfully newer languages like Nim, Odin, and Swift lean hard into value semantics. They drastically reduce the cost of focusing on data structures and writing obvious algorithms. Then, when bottlenecks appear, you can choose to opt into fine-tuning.
Rule 4, I have always practiced and demanded of junior programmers, to make algorithms and structures that are simple to understand, for our main user: the one who will modify this code in the future.
I believe that's why Golang is a very simple but powerful language.
Electron.js took this concept a bit too far.
Take a look at the page title. I guess he didn't follow his own rules for this 100-line HTML file
<title> <h1>Rob Pike's 5 Rules of Programming</h1> </title>
Rule 1 seems similar to Donald Knuths "premature optimization" from 1974.
> Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.
Rule 2 follows rule 1.
Rule 3 & 4 is a variation of Keep it Simple, Stupid (KISS) from the 1960s.
... and... now I feel stupid, because I read the last part, which is summarizing it in the same way.
I'm not a skilled programmer (but would like to be someday). Would someone kindly resolve what appears to me to be a contradiction between the following?
1(a) Torvalds: "Bad programmers worry about the code. Good programmers worry about data structures and their relationships."
1(b) Pike Rule 5: "Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming."
— versus —
2. Perlis 2: "Functions delay binding; data structures induce binding. Moral: Structure data late in the programming process."
---
Ignorant as I am, I read these to advise that I ought to put data structures centrally, first, foremost — but not until the end of the programming process.
> Pike's rules 1 and 2 restate Tony Hoare's famous maxim "Premature optimization is the root of all evil."
This thing never resonated with me.
I often hear it as an excuse to ignore “optimization” at all.
It’s like “broken windows” theory. This allows slop, rot, and technical debt in. And it spreads fast.
Also if everything is unoptimized, this is not what could be easily fixed.
Death of thousand cuts, if you will.
does _a speed hack_ mean adding time.Sleep() for testing? or it's something else?
never expected it to be a single HTML file so kind of surprised, but straight to the point, to be honest.
Heretical opinion:
I think that Rob Pike was far more of a wordcel than a shape rotator for a famous computer scientist (which historically were very much on the shape rotator side).
Rob Pike is programming God of retardmaxxing. Go programming language is a good example of this, where it was the dumbest language for a longgg time.
Even agree with most of the stuff he said, however in real life, you won't be able to win a fight using these arguments. You can only create a environment to execute these strategies first to get a good product and them use them as a propaganda afterwards.
Great rules, but Rule 3.: WOW, so true, so well enunciated, masterful.
I received some 'interesting' feedback when I spoke about commenting that I was using an O(n) search instead of an O(log n) algorithm because of the normally small size of n [0]
What I should have done was point to Rob's third rule (either in my comment or in the resulting threads)
[0] https://news.ycombinator.com/threads?id=awesome_dude&next=47...
Rule 5 should be rule 1.
9front it's distilled Unix. I corrected Russ Cox' 'xword' to work in 9front and I am just a newbie. No LLM's, that's Idiocratic, like the movie; just '9intro.us.pdf' and man pages.
LLM's work will never be reproducible by design.
Golden rules for sure!
Uuuh doesn't look good that you claim something is important enough to be in your top 5, but then misattribute it.
I think I’m going to copy and paste this directly into my AGENTS.md file!
Seem logical
Rule 6: Never disagree with AI slop
"Rule 6: Don't waste time on syntax highlighting unless you're incompetent."
[dead]
[dead]
[flagged]
[dead]
[dead]
[dead]
[dead]
[flagged]
[dead]
[dead]
How quaint. I hope Claude/Codex reads this since from what I've heard here I'm not likely to need this rules anymore /s I am curious if anyone has attempted to use codex/claude with something like this in the prompt
[dead]
[dead]
[dead]
Great gonna add these to my CLAUDE.md /s
[dead]
[flagged]
CS Unc remains un-chopped.
I suppose this makes me feel a little bit better about a multi-month process that ended up requiring the eight Queens problem.
That said management did not quite understand. They thought that I should have known about the bottleneck (Actually I did but I was told not to prematurely optimize)
I end up writing the program three times, the final solution was honestly beautiful.
Management was not happy. The customer was happy.