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

41–50 of 483 posts

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

#41

Post by neocron »

andsoitis wrote: post #30
bfivyvysj wrote: post #19

Earlier quoted context omitted.

This is the biggest issue I see with AI driven development. The data structures are incredibly naive. Yes it's easy to steer them in a different direction but that comes at a long term cost. The further you move from naive the more often you will need to resteer downstream and no amount of context management will help you, it is fighting against the literal mean.

> This is the biggest issue I see with AI driven development. The data structures are incredibly naive. Bill Gates, for example, always advocated for thinking through the entire program design and data structures before writing any code, emphasizing that structure is crucial to success.

Ah Bill Gates, the epitome of good software

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

#42

Post by Intermernet »

relaxing wrote: post #25
CharlieDigital wrote: post #18

I feel like 1 and 2 are only applicable in cases of novelty. The thing is, if you build enough of the same kinds of systems in the same kinds of domains, you can kinda tell where you should optimize ahead of time. Most of us tend to build the same kinds of systems and usually spend a career or a good chunk of our careers in a given domain. I feel like you can't really be considered a staff/principal if you can't alre…

Rob Pike wrote Unix and Golang, but sure, you’re built different.

Rob Pike is responsible for many cool things, but Unix isn't one of them. Go is a wonderful hybrid (with its own faults) of the schools of Thompson and Wirth, with a huge amount of Pike.

If you'd said Plan 9 and UTF-8 I'd agree with you.

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

#43

Post by DrScientist »

mosura wrote: post #16
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…

> 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 after thought, whereas Rule 5 is spot on. It is? How can you conceive of a precise idea of how to solve a problem without a similarly precise idea of how you intend to represent the information fundamental to it? They are inseparable.

Obviously they are linked - the question is where do you start your thinking.

Do you start with the logical task first and structure the data second, or do you actually think about the data structures first?

Let's say I have a optimisation problem - I have a simple scoring function - and I just want to find the solution with the best score. Starting with the logic.

for all solutions, score, keep if max.

Simple eh? Problem is it's a combinatorial solution space. The key to solving this before the entropic death of the universe is to think about the structure of the solution space.

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

#44

Post by Bengalilol »

CharlieDigital wrote: post #18

I feel like 1 and 2 are only applicable in cases of novelty. The thing is, if you build enough of the same kinds of systems in the same kinds of domains, you can kinda tell where you should optimize ahead of time. Most of us tend to build the same kinds of systems and usually spend a career or a good chunk of our careers in a given domain. I feel like you can't really be considered a staff/principal if you can't alre…

> you can kinda tell where you should optimize ahead of time

Rules are "kinda" made to be broken. Be free.

I've been sticking to these rules (and will keep sticking to them) for as long as I can program (I've been doing it for the last 30 years).

IMHO, you can feel that a bottleneck is likely to occur, but you definitely can't tell where, when, or how it will actually happen.

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

#45

Post by Intermernet »

swiftcoder wrote: post #8
kleiba wrote: post #4

I believe the "premature evil" quote is by Knuth, not Hoare?!

Potentially its by either (or even both independently). Knuth originally attributed it to Hoare, but there's no paper trail to demonstrate Hoare actually coined it first

Turns out that premature attribution is actually the root of all evil...

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

#47

Post by Bengalilol »

swiftcoder wrote: post #8
kleiba wrote: post #4

I believe the "premature evil" quote is by Knuth, not Hoare?!

Potentially its by either (or even both independently). Knuth originally attributed it to Hoare, but there's no paper trail to demonstrate Hoare actually coined it first

Every empirical programmer will, at some point, end up yelling it out loud (too).

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

#48

Post by jacquesm »

mosura wrote: post #5
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…

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

Perlis is right in the way that academics so often are and Pike is right in the way that practitioners often are. They also happen to be in rough agreement on this, unsurprisingly so.

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

#49

Post by Hendrikto »

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…

I feel like these are far more vague and less actionable than the 5 Pike rules.

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

#50

Post by DaleBiagio »

The attribution to Hoare is a common error — "Premature optimization is the root of all evil" first appeared in Knuth's 1974 paper "Structured Programming with go to Statements."

Knuth later attributed it to Hoare, but Hoare said he had no recollection of it and suggested it might have been Dijkstra.

Rule 5 aged the best. "Data dominates" is the lesson every senior engineer eventually learns the hard way.

Post reply on HN