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

201–210 of 483 posts

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

#201

Post by bluGill »

seanalltogether wrote: post #156
TYPE_FASTER wrote: post #88

Earlier quoted context omitted.

> 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 requireme…

Related: your business logic should work on metric units. It is a UI concern if the user wants to see some other measurement system. Convert to feet, chains, cubits... or whatever obscure measurement system the user wants at display time. (if you do get an embedded device that reports non-metric units convert when it comes in - you will get a different device in the future that reports different units anyway)

You still have to worry about someone using kg when you use g, but you avoid a large class of problems and make your logic easier.

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

#202

Post by AnimalMuppet »

mosura wrote: post #84
AnimalMuppet wrote: post #79

Earlier quoted context omitted.

Could you be more specific?

Promoting the idea of one data structure with many functions contradicts: “If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident.” And: “Use simple algorithms as well as simple data structures.” A data structure general enough to solve enough problems to be meaningful will either be poorly suited to some problems or have complex algorithms for those pr…

I think you are badly misinterpreting the statement.

Let's say you're working for the DMV on a program for driver's licenses. The idea is to use one structure for driver's license data, as opposed to using one structure for new driver's licenses, a different one for renewals, and yet a third for expired ones, and a fourth one for name changes.

It is not saying that you should use byte arrays for driver's license records, so that you can use the same data structure for driver's license data and missile tracks. Generalize within your program, not across all possible programs running on all computers.

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

#203

Post by devnullbrain »

pydry wrote: post #173
kalaksi wrote: post #111

Earlier quoted context omitted.

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 "t…

>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.

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

#204

Post by sayYayToLife »

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.

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

#205

Post by lynndotpy »

devnullbrain wrote: post #101
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,…

> and the missing context is essential. 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.

Yep. If one is implementing quicksort for a library where it will be used and relied on, I'd sure hope they're optimizing it as much as they can.

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

#206

Post by mchaver »

embedding-shape wrote: post #78
mchaver wrote: post #57

Earlier quoted context omitted.

I find languages like Haskell, ReScript/OCaml to work really well for CRUD applications because they push you to think about your data and types first. Then you think about the transformations you want to make on the data via functions. When looking at new code I usually look for the types first, specifically what is getting stored and read.

Similarly, that approach works really well in Clojure too, albeit with a lot less concern for types, but the "data and data structures first" principle is widespread in the ecosystem.

I've heard good things about Clojure, and it'ss different from what I am used to (bonus points because I like an intellectual challenge), so trying it out is definitely on my todo list.

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

#208

Post by bob1029 »

patwolf wrote: post #198

These rules apply equally well to system architecture. I've been trying to talk our team out of premature optimization (redis cluster) and fancy algorithms (bloom filters) to compensate for poor data structures (database schema) before we know if performance is going to be a problem. Even knowing with 100% certainty that performance will be subpar, requirements change often enough that it's often not worth the cost o…

> Even knowing with 100% certainty that performance will be subpar

I think there is value in attempting to do something the "wrong way" on purpose to some extent. I have walked into many situations where I was beyond convinced that the performance of something would suck only to be corrected harshly by the realities of modern computer systems.

Framing things as "yes, I know the performance is definitely not ideal in this iteration" puts that monkey in a proper cage until the next time around. If you don't frame it this way up front, you might be constantly baited into chasing the performance monkey around. Its taunts can be really difficult to ignore.

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

#209

Post by thecodemonkey »

Running the same codebase for 10+ years with a small team is what finally made me fully internalize these rules.

I've always been a KISS/DRY person but over a decade there are plenty of moments where you're tempted to reach for a fancier database or rewrite something in a trendier stack. What's actually kept things running well at scale is boring, known technologies and only optimizing in the places where it actually matters.

We wrote our principles down recently and it basically just reads like Pike's rules in different words: https://www.geocod.io/code-and-coordinates/2025-09-30-develo...

Post reply on HN