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

131–140 of 483 posts

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

#131

Post by 0xpgm »

radlad wrote: post #124
0xpgm wrote: post #62

Earlier quoted context omitted.

Reminded me of this thread between Alan Kay and Rich Hickey where Alan Kay thinks "data" is a bad idea. My interpretation of his point of view is that what you need is a process/interpreter/live object that 'explains' the data. https://news.ycombinator.com/item?id=11945722 EDIT: He writes more about it in Quora. In brief, he says it is 'meaning', not 'data' that is central to programming. https://qr.ae/pCVB9m

Hm, not sure. Data on its own (say, a string of numbers) might be meaningless - but structured data? Sure, there may be ambiguity but well-structured data generally ought to have a clear/obvious interpretation. This is the whole idea of nailing your data structures.

Yeah, structured data implies some processing on raw data to improve its meaning. Alan Kay seems to want to push this idea to encapsulate data with rich behaviour.

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

#133

Post by treetalker »

I'm not a skilled programmer (but would like to be someday). Would someone kindly resolve what appears to me to be a contradiction between the following?

1(a) Torvalds: "Bad programmers worry about the code. Good programmers worry about data structures and their relationships."

1(b) Pike 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."

— versus —

2. Perlis 2: "Functions delay binding; data structures induce binding. Moral: Structure data late in the programming process."

---

Ignorant as I am, I read these to advise that I ought to put data structures centrally, first, foremost — but not until the end of the programming process.

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

#134

Post by colechristensen »

sph wrote: post #120
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,…

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…

Ehh, people who are really excited about DRY write unreadable convoluted code, where the bulk of the code is abstractions invented to avoid rewriting a small amount of code and unless you're very familiar with the codebase reasoning about what it actually does is a mystery because related pieces of functionality are very far away from each other.

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

#135

Post by dkarl »

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 optimization is the root of all evil" invoked to support opposite sides of the same argument. Pike's rules are much clearer and harder to interpret creatively.

Also, it's amusing that you don't hear this anymore:

> Rule 5 is often shortened to "write stupid code that uses smart objects".

In context, this clearly means that if you invest enough mental work in designing your data structures, it's easy to write simple code to solve your problem. But interpreted through an OO mindset, this could be seen as encouraging one of the classic noob mistakes of the heyday of OO: believing that your code could be as complex as you wanted, without cost, as long as you hid the complicated bits inside member methods on your objects. I'm guessing that "write stupid code that uses smart objects" was a snappy bit of wisdom in the pre-OO days and was discarded as dangerous when the context of OO created a new and harmful way of interpreting it.

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

#136

Post by colechristensen »

treetalker wrote: post #133

I'm not a skilled programmer (but would like to be someday). Would someone kindly resolve what appears to me to be a contradiction between the following? 1(a) Torvalds: "Bad programmers worry about the code. Good programmers worry about data structures and their relationships." 1(b) Pike Rule 5: "Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be…

That is indeed contradictory and what those things say.

Good structure comes from exploring until you understand the problem well AND THEN letting data structure dominate.

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

#137

Post by 0xpgm »

gregw2 wrote: post #129
0xpgm wrote: post #62

Earlier quoted context omitted.

Reminded me of this thread between Alan Kay and Rich Hickey where Alan Kay thinks "data" is a bad idea. My interpretation of his point of view is that what you need is a process/interpreter/live object that 'explains' the data. https://news.ycombinator.com/item?id=11945722 EDIT: He writes more about it in Quora. In brief, he says it is 'meaning', not 'data' that is central to programming. https://qr.ae/pCVB9m

Thanks for the pointer to this 2016 dialog! One part of it has interesting new resonance in the era of agentic LLMs: alankay on June 21, 2016 | root | parent | next [–] This is why "the objects of the future" have to be ambassadors that can negotiate with other objects they've never seen. Think about this as one of the consequences of massive scaling ... Nowdays rather than the methods associated with data objects, w…

Quite a nice insight there!

I should probably be thinking more in this direction.

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

#138

Post by lowmagnet »

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

I always point out the operational word is "premature".

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

#139

Post by matthewkayin »

sph wrote: post #120
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,…

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 somehow abstract out for loops because I'm repeating myself.

But if I have logic that says that button_b.x = button_a.x + button_a.w + padding, then I should make sure that I only write that information down once, so that it stays consistent throughout the program.

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

#140

Post by [deleted] »

sph wrote: post #120
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,…

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…

[deleted]
Post reply on HN