Rob Pike’s Rules of Programming (1989)

Post by mosura » Wed, Mar 18, 2026, 2:35 PM UTC

AnimalMuppet wrote: post #202

mosura wrote: post #84

Earlier quoted context omitted.

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

Post by rkomorn » Wed, Mar 18, 2026, 2:36 PM UTC

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…

Post by pdpi » Wed, Mar 18, 2026, 2:37 PM UTC

Post by ndriscoll » Wed, Mar 18, 2026, 2:37 PM UTC

embedding-shape wrote: post #170

ndriscoll wrote: post #165

Earlier quoted context omitted.

IME doing application servers and firmware my whole career, simple and fast are usually the same thing, and "simple secure" is usually better security posture than "complex secure".

Interesting, never done firmware, but plenty of backends and frontends. Besides the whole "do less and things get faster", I can't think of a single case where "simple" and "fast" is the same thing. And I'd agree that "simple secure" is better than "complex secure" but you're kind of side-stepping what I said, what about "not secure at all", wouldn't that lead to simpler code? Usually does for me, especially if you h…

Post by vbezhenar » Wed, Mar 18, 2026, 2:41 PM UTC

Megranium wrote: post #185

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

Huh, I've always understood that quote very differently, with emphasis on "premature" ... not as in, "don't optimize" but more as in "don't optimize before you've understood the problem" ... or, as a CS professor of mine said "Make it work first, THEN make it work fast" ...