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

471–480 of 483 posts

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

#471

Post by tehnub »

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…

There's probably tons of stuff people use that is way slower than it needs to be but speed isn't one of their self-reported burning problems because they don't even realize it could be faster. pip vs uv?

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

#472

Post by rglynn »

zephen wrote: post #432
pydry wrote: post #332

Earlier quoted context omitted.

Going "what if?" and then validating a customer requirement that exists NOW is NOT the same thing as trying to pre-empt a customer's requirement which might exist in the future. Audit trails are commonly neglected coz somebody didnt ask the right questions, not coz somebody didnt try to anticipate the future.

> Audit trails are commonly neglected coz somebody didnt ask the right questions, not coz somebody didnt try to anticipate the future. But how do you ask "the right questions" without imagining many future possibilities and then trying to discern which ones are important? It seems like a distinction without a difference to me.

Imagining future possibilities and implementing software to account for them are two different things.

The argument here is to validate those possibilities before acting on them.

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

#473

Post by dkarl »

kevincox wrote: post #328
01100011 wrote: post #252

Rule 3 gets me into trouble with CS majors a lot. I'm an EE by education and entered into SW via the bottom floor(embedded C/ASM) so it was late in my career before I knew the formal definition of big-O and complexity. For most of my career, sticking to rule 3 made the most sense. When the CS major would be annoying and talk about big-O they usually forgot n was tiny. But then my job changed. I started working on dif…

I actually disagree with Rule 3! While numbers are usually small being fast on small cases generally isn't as important as performing acceptably on large cases. So I prefer to take the better big-O so that it doesn't slow down unacceptably on real-world edge-case stresses. (The type of workloads that the devs often don't experience but your big customers will.) Of course there is a balance to this, the engineering ti…

I think it's important to think about architectural and domain bounds on problems and check if the big-O-optimal algorithm ever comes out on top. I remember Bjarne Stroustrup did a lecture where he compared a reasonably-implemented big-O-optimal algorithm on linked lists to a less optimal algorithm using arrays, and he used his laptop to test at what data size the big-O-optimal algorithm started to beat the less optimal algorithm. What he found was that the less optimal algorithm beat the big-O-optimal algorithm for every dataset he could process on the laptop. In that case, architectural bounds meant that the big-O-optimal algorithm was strictly worse. That was an extreme case, but it shows the value of testing.

Domain bounds can be dangerous to rely on, but not always. For example, the number of U.S. states is unlikely to change significantly in the lifetime of your codebase.

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

#474

Post by dkarl »

Matthyze wrote: post #372
dkarl wrote: post #135

I think it's fine and generous that he credited these rules to the better-known aphorisms that inspired them, but I think his versions are better, they deserve to be presented by themselves, instead of alongside the mental clickbait of the classic aphorisms. They preserve important context that was lost when the better-known versions were ripped out of their original texts. For example, I've often heard "premature op…

"mental clickbait of the classic aphorisms" is one way to phrase 'attribution"

I guess what I mean by that is that Rob Pike was obviously aware that his rules were not as catchy and pithy as the aphorisms he credited, and his only reason for writing his rules was to improve on them by making them more explicit and less prone to user error. But presenting his versions alongside the more catchy ones means that every time people read them, the catchy ones distract attention and remain more memorable than the improved versions.

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

#475

Post by zephen »

rglynn wrote: post #472
zephen wrote: post #432

Earlier quoted context omitted.

> Audit trails are commonly neglected coz somebody didnt ask the right questions, not coz somebody didnt try to anticipate the future. But how do you ask "the right questions" without imagining many future possibilities and then trying to discern which ones are important? It seems like a distinction without a difference to me.

Imagining future possibilities and implementing software to account for them are two different things. The argument here is to validate those possibilities before acting on them.

> Imagining future possibilities and implementing software to account for them are two different things.

True.

> The argument here is to validate those possibilities before acting on them.

I agree this should be done. It's not clear that was the original argument, because the same guy previously wrote:

> The number 1 issue Ive experienced with poor programmers is a belief that theyre special snowflakes who can anticipate the future.

"The future" is a not-so-special case of "the now."

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

#477

Post by IIsi50MHz »

JanisErdmanis wrote: post #63
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…

With 100 functions and one datastructure it is almost as programming with a global variables where new instance is equivalent to a new process. Doesn’t seem like a good rule to follow.

"one data structure" doesn not have to mean "all data it one instance". Each of 100 functions could take a slice of data, or use a separate datastore which has the same structure. Separate instances of one structure can be passed by reference or value, and the receiver, because all 100 functions use the same data structure, understands what to do with what it received.

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

#478

Post by [deleted] »

miloignis wrote: post #174
tikhonj wrote: post #166

Earlier quoted context omitted.

The rule of 3 is awful because it focuses on the wrong thing. If two instances of the same logic represent the same concept, they should be shared. If 10 instances of the same logic represent unrelated concepts, they should be duplicated. The goal is to have code that corresponds to a coherent conceptual model for whatever you are doing, and the resulting codebase should clearly reflect the design of the system. Once…

Of course, the rule of 3 is saying that you often _can't tell_ what the shared concept between different instances is until you have at least 3 examples. It's not about copying identical code twice, it's about refactoring similar code into a shared function once you have enough examples to be able to see what the shared core is.

[deleted]

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

#479

Post by anymouse123456 »

Someone wrote: post #287
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,…

> From his 1974 paper, "Structured Programming with go to Statements": > He was talking about using GOTO statements in C. I don’t think he was talking about C. That paper is from December 1974, and (early) C is from 1972, and “The UNIX Time-Sharing System” ( https://dsf.berkeley.edu/cs262/unix.pdf ) is from July 1974, so time wise, he could have known C, but AFAICT that paper doesn’t mention C, and the examples are P…

I kind of love this. Thanks for the correction!

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

#480

Post by anymouse123456 »

ndriscoll wrote: post #165
embedding-shape wrote: post #112

Earlier quoted context omitted.

User-facing, sure, nothing stopping us from doing "simple and fast" software. But when it comes to the code, design and architecture, "simple" is often at odds with "fast", and also "secure". Once you need something to be fast and secure, it often leads to a less simple design, because now you care about more things, it's kind of hard to avoid.

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

Same experience here and even more powerfully illustrated in firmware development.
Post reply on HN