Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rob Pike’s Rules of Programming (1989)

cs.unc.edu

Post reply on HN
Print view View original

151–160 of 483 posts

Re: Rob Pike’s Rules of Programming (1989)

#151

Post by hackemmy »

sph wrote: post #120
anymouse123456 wrote: post #93

There are very few phrases in all of history that have done more damage to the project of software development than: "Premature optimization is the root of all evil." First, let's not besmirch the good name of Tony Hoare. The quote is from Donald Knuth, and the missing context is essential. From his 1974 paper, "Structured Programming with go to Statements": "Programmers waste enormous amounts of time thinking about,…

Another one from my personal experience: apply DRY principles (don't repeat yourself) the third time you need something. Or in other words: you're allowed to copy-and-paste the same piece of code in two different places. Far too often we generalise a piece of logic that we need in one or two places, making things more complicated for ourselves whenever they inevitably start to differ. And chances are very slim we wil…

This is so true. I have been burned by this more times than I can count. You see two functions that look similar, you extract a shared utility, and then six months later one of them needs a slightly different behavior and now you are fighting your own abstraction instead of just changing one line in a copy. The rule of three is a good default. Let the pattern prove itself before you try to generalize it.

Re: Rob Pike’s Rules of Programming (1989)

#152

Post by clktmr »

andsoitis wrote: post #83
ozgrakkurt wrote: post #33

Earlier quoted context omitted.

Would be cool to see the live reaction of Rob Pike to this comment

> Would be cool to see the live reaction of Rob Pike to this comment Based on everything public, Pike is deeply hostile to generative AI in general: - The Christmas 2025 incident ( https://simonwillison.net/2025/Dec/26/slop-acts-of-kindness/ ) - he's labeled GenAI as nuclear waste ( https://www.webpronews.com/rob-pike-labels-generative-ai-nuc... ) - ideologically, he's spent his career chasing complexity reduction, a…

> - he's labeled GenAI as nuclear waste (https://www.webpronews.com/rob-pike-labels-generative-ai-nuc...)

The whole article is an AI hallucination. It refers to the same "Christmas 2025 incident". The internet is dead for real.

Re: Rob Pike’s Rules of Programming (1989)

#153

Post by mosura »

embedding-shape wrote: post #90
Pxtl wrote: post #77

Earlier quoted context omitted.

As much as relational DBs have held back enterprise software for a very long time by being so conservative in their development, the fact that they force you to put this relationship absolutely front-of-mind is excellent .

I'd personally consider "persistence" AKA "how to store shit" to be a very different concern compared to the data structures that you use in the program. Ideally, your design shouldn't care about how things are stores, unless there is a particular concern for how fast things read/writes.

Often significant improvements to every aspect of a system that interacts with a database can be made by proper design of the primary keys, instead of the generic id way too many people jump to.

The key difficulty is identifying what these are is far from obvious upfront, and so often an index appears adjacent to a table that represents what the table should have been in the first place.

Re: Rob Pike’s Rules of Programming (1989)

#154

Post by UncleMeat »

sph wrote: post #120
anymouse123456 wrote: post #93

There are very few phrases in all of history that have done more damage to the project of software development than: "Premature optimization is the root of all evil." First, let's not besmirch the good name of Tony Hoare. The quote is from Donald Knuth, and the missing context is essential. From his 1974 paper, "Structured Programming with go to Statements": "Programmers waste enormous amounts of time thinking about,…

Another one from my personal experience: apply DRY principles (don't repeat yourself) the third time you need something. Or in other words: you're allowed to copy-and-paste the same piece of code in two different places. Far too often we generalise a piece of logic that we need in one or two places, making things more complicated for ourselves whenever they inevitably start to differ. And chances are very slim we wil…

More critical in my mind is investigating the "inevitably start to differ" option.

If two pieces of code use the same functionality by coincidence but could possibly evolve differently then don't refactor. Don't even refactor if this happens three, four, or five times. Because even if the code may be identical today the features are not actually identical.

But if you have two uses of code that actually semantically identical and will assuredly evolve together then go ahead and refactor to remove duplication.

Re: Rob Pike’s Rules of Programming (1989)

#156

Post by seanalltogether »

TYPE_FASTER wrote: post #88
embedding-shape wrote: post #2

"Epigrams in Programming" by Alan J. Perlis has a lot more, if you like short snippets of wisdom :) https://www.cs.yale.edu/homes/perlis-alan/quotes.html > 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. Always preferred Perlis' version, that might be slightly o…

> 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. If I have learned one thing in my 30-40 years spent writing code, it is this.

I agree. The biggest lesson I try to drive home to newer programmers that join my projects is that its always best to transform the data into the structure you need at the very end of the chain, not at the beginning or middle. Keep the data in it's purest form and then transform it right before displaying it to the user, or right before providing it in the final api for others to consume.

You never know how requirements are going to change over the next 5 years, and pure structures are always the most flexible to work with.

Re: Rob Pike’s Rules of Programming (1989)

#157

Post by globular-toast »

anymouse123456 wrote: post #93

There are very few phrases in all of history that have done more damage to the project of software development than: "Premature optimization is the root of all evil." First, let's not besmirch the good name of Tony Hoare. The quote is from Donald Knuth, and the missing context is essential. From his 1974 paper, "Structured Programming with go to Statements": "Programmers waste enormous amounts of time thinking about,…

So you're saying people have misunderstood "premature optimisation is the root of all evil" as "optimisation is the root of all evil"?

I don't think you can blame this phrase if people are going to drop an entire word out of an eight word sentence. The very first word, no less.

Re: Rob Pike’s Rules of Programming (1989)

#158

Post by nostrademons »

matthewkayin wrote: post #139
sph wrote: post #120

Earlier quoted context omitted.

Another one from my personal experience: apply DRY principles (don't repeat yourself) the third time you need something. Or in other words: you're allowed to copy-and-paste the same piece of code in two different places. Far too often we generalise a piece of logic that we need in one or two places, making things more complicated for ourselves whenever they inevitably start to differ. And chances are very slim we wil…

I think we should not even generalize it down to a rule of three, because then you're outsourcing your critical thinking to a rule rather than doing the thinking yourself. Instead, I tend to ask: if I change this code here, will I always also need to change it over there? Copy-paste is good as long as I'm just repeating patterns. A for loop is a pattern. I use for loops in many places. That doesn't mean I need to som…

The reason for the rule of thumb is because you don't know whether you will need to change this code here when you change it there until you've written several instances of the pattern. Oftentimes different generalizations become appropriate for N=1, N=2, N>=3 && N =10 && N=100.

Your example is a pretty good one. In most practical applications, you do not want to be setting button x coordinates manually. You want to use a layout manager, like CSS Flexbox or Jetpack Compose's Row or Java Swing's FlowLayout, which takes in a padding and a direction for a collection of elements and automatically figures out where they should be placed. But if you only have one button, this is overkill. If you only have two buttons, this is overkill. If you have 3 buttons, you should start to realize this is the pattern and reach for the right abstraction. If you get to 10 buttons, you'll realize that you need to arrange them in 2D as well and handle how they grow & shrink as you resize the window, and there's a good chance you need a more powerful abstraction.

Re: Rob Pike’s Rules of Programming (1989)

#159

Post by pydry »

twoodfin wrote: post #117
anymouse123456 wrote: post #93

There are very few phrases in all of history that have done more damage to the project of software development than: "Premature optimization is the root of all evil." First, let's not besmirch the good name of Tony Hoare. The quote is from Donald Knuth, and the missing context is essential. From his 1974 paper, "Structured Programming with go to Statements": "Programmers waste enormous amounts of time thinking about,…

Ignoring optimization opportunities until you see the profile only works when you actually profile! Profiling never achieved its place in most developers’ core loop the way that compiling, linting, or unit testing did. How many real CI/CD pipelines spit out flame graphs alongside test results?

I usually defer this until a PM does the research to highlight that speed is a burning issue.

I find 98% of the time that users are clamoring to get something implemented or fixed which isnt speed related so I work on that instead.

When I do drill down what I tend to find in the flame graphs is that your scope for making performance improvements a user will actually notice is bottlenecked primarily by I/O not by code efficiency.

Meanwhile my less experienced coworkers will spot a nested loop that will never take more than a couple of milliseconds and demand it be "optimised".

Re: Rob Pike’s Rules of Programming (1989)

#160

Post by zweifuss »

treetalker wrote: post #133

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…

When you explore a problem, use Python and lists/sets/dictionaries/JSON. Wait with types and specific data structures till you have understanding. Speed of development over speed of execution.

When you know what and how to build commit to good data structures. Do the types, structs, classes, Trie, CRDTs, XML, Protobuf, Parquet and whatnot where apropriate. Instrument your program. The efficiency of the final product counts.

Post reply on HN