Rob Pike’s Rules of Programming (1989)

http://users.ece.utexas.edu/~adnan/pike.html

by sirkarthik • 9 years ago

58 18 9 years ago

users.ece.utexas.edu

khanjahanzaib27• 9 years ago

That is pretty nice topic.

lower• 9 years ago

Pike's rules 1 and 2 restate Tony Hoare's famous maxim "Premature optimization is the root of all evil."

That quote is from Knuth, not Hoare.

https://shreevatsa.wordpress.com/2008/05/16/premature-optimi...

pvg• 9 years ago

The Hoare attribution is also (at least in part) due to Knuth so it all comes out about even in the end.

Tehnix• 9 years ago

These are all well and good, as long as you remember not to blindly live by them (which you'll often see people do with advice from authority).

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.

I'm not sure what the author wants me to take away from this? Data structures and algorithms should very much both be taken into consideration, although I'd agree that "it all starts with the choice data structure".

cdoxsey• 9 years ago

All too often we focus on performance as the main problem we're trying to solve, when, in reality, our chief problem is managing complexity.

A clever algorithm can often dramatically improve performance, but usually clever algorithms are difficult to understand and their unmaintainability leads them to be abandoned as a project evolves, or, worse, subtly break when assumptions no longer hold. (Its especially hard when working with other developers)

The only example that was coming immediately to mind was a distributed lock. Once you have that primitive available your distributed systems problem can be substantially simpler to implement. Without it writing race-free code is going to be really tricky.

mrweasel• 9 years ago

I really like rule 5. It's can be extremely hard to get data structures right, but you really notice when you do. I had the chance to redo a project, and the biggest chances was to how data was structured and it made a world of difference.

ambrosite• 9 years ago

I have found this to be true as well. The first thing I do whenever reviewing an open source project is to examine the database schema. I can usually figure out what the code does and how it works by looking at the tables and the relationships between them.

MrBuddyCasino• 9 years ago

Linus agrees: „…git actually has a simple design, with stable and reasonably well-documented data structures. In fact, I'm a huge proponent of designing your code around the data, rather than the other way around, and I think it's one of the reasons git has been fairly successful […] 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.“

dagw• 9 years ago

Understanding and living by Rule 5 is, in my book, what separates good and great programmers.

discoursism• 9 years ago

I can't even remember all the times this has hit me. Often times, I'll be working on a module, and the code will just be ugly, hard to understand, hard to write. Then, I'll make a small change to the organization of the data structures I'm working on (normally, literally a change in the set of data that is a field of one struct or another, or a parameter to one function or another) and suddenly everything will become clear. These days, if code is getting ugly, the first thing I try to do is look at whether the relevant data is logically grouped, because nine times out of ten, this ends up being the problem. I only wish I was better at getting it right the first time.

jacquesm• 9 years ago

Link change?

http://users.ece.utexas.edu/~adnan/pike.html

nerdponx• 9 years ago

Content is shamelessly copy-pasted from http://users.ece.utexas.edu/~adnan/pike.html*

Reply

dang• 9 years ago

Yes. Changed from http://blog.codonomics.com/2017/09/rob-pikes-5-rules-of-prog....

It's also a dupe: https://hn.algolia.com/?query=pike%20rules&sort=byDate&dateR...

Reply

sirkarthik• 9 years ago

I've witnessed the unfortunate consequences when each of these rules were violated.

I've seen kludgy code when Rules 1 and 2 are violated for instance.

Employing Fancy algorithms to look good among peers, leaving behind buggy and maintainable code.

Rule 5 violation is deceptive. Often one can get it right with right understanding of business use-case.

The worst part is not the violation of these rules but the developer's chest-thumping with pride for writing seemingly intelligent code :-/

Reply

zebraflask• 9 years ago

Sound principles, as usual.

Reply

1_2__4• 9 years ago

On one hand I love these and consider them good advice. On the ther they’re often used as a weak crutch for poor programming practices, usually by developers who believe any amount of money spent on infrastructure is worth it to avoid the catastrophic consequences of maybe thinking about performance in their code. They’re certain they never want to optimize too early, and they’re certain that every day is too early.

Reply

herodotus• 9 years ago

Rod Burstall of Edinburgh University said pithily: "Efficiency is the enemy of clarity"

Rob Pike’s Rules of Programming (1989)

Related Stories