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

81–90 of 483 posts

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

#81

Post by DrScientist »

TheOtherHobbes wrote: post #74
DrScientist wrote: post #10

Earlier quoted context omitted.

I think for people starting out - rule 5 isn't perhaps that obvious. > 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 want to solve a problem - it's natural to think about logic flow and the code that implements that first and the data structures are an afte…

I mean - no. If you're coming to a completely new domain you have to decide what the important entities are, and what transformations you want to apply. Neither data structures nor algorithms, but entities and tasks, from the user POV, one level up from any kind of implementation detail. There's no point trying to do something if you have no idea what you're doing, or why. When you know the what and why you can start…

Sure context is important - and the important context you appear to have missed is the 5 rules aren't about building websites. It's about solving the kind of problems which are easy to state but hard to do (well) .

eg sort a list.

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

#82

Post by WillAdams »

linhns wrote: post #59
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…

Nice to see Perlis mentioned once in a while. Reading SICP again, still learning new things.

There is a matching video series for SICP:

https://ocw.mit.edu/courses/6-001-structure-and-interpretati...

which I found very helpful in (finally) managing to get through that entire text (and do all the exercises).

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

#83

Post by andsoitis »

ozgrakkurt wrote: post #33
tobwen wrote: post #13

Added to AGENTS.md :)

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, adovcating for code sobriety, resource efficiency, and clarity of thought. Large, opaque, energy-intensive LLMs represent the antithesis.

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

#84

Post by mosura »

AnimalMuppet wrote: post #79
mosura wrote: post #5

Earlier quoted context omitted.

Perlis is just wrong in that way academics so often are. Pike is right.

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 problems, or both.

There are reasons we don’t all use graph databases or triple stores, and rely on abstractions over our byte arrays.

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

#85

Post by skydhash »

wwweston wrote: post #27
tobwen wrote: post #13

Added to AGENTS.md :)

How good is your model at picking good data structures? There’s several orders of magnitude less available discussion of selecting data structures for problem domains than there is code. If the underlying information is implicit in high volume of code available then maybe the models are good at it, especially when driven by devs who can/will prompt in that direction. And that assumption seems likely related to how mu…

> There’s several orders of magnitude less available discussion of selecting data structures for problem domains than there is code.

I believe that’s what most algorithms books are about. And most OS book talks more about data than algorithms. And if you watch livestream or read books on practical projects, you’ll see that a lot of refactor is first selecting a data structure, then adapt the code around it. DDD is about data structure.

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

#86

Post by mikepurvis »

rsav wrote: post #9
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…

There's also: >I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships. -- Linus Torvalds

I think this is sometimes a barrier to getting started for me. I know that I need to explore the data structure design in the context of the code that will interact with it and some of that code will be thrown out as the data structure becomes more clear, but still it can be hard to get off the ground when me gut instinct is that the data design isn't right.

This kind of exploration can be a really positive use case for AI I think, like show me a sketch of this design vs that design and let's compare them together.

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

#87

Post by tangus »

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…

Aren't they basically saying opposite things? Perlis is saying "don't choose the right data structure, shoehorn your data into the most popular one". This advice might have made sense before generic programming was widespread; I think it's obsolete.

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

#88

Post by TYPE_FASTER »

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.

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

#90

Post by embedding-shape »

Pxtl wrote: post #77
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…

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.
Post reply on HN