
Rob Pike's 5 Rules of Programming - sirkarthik
http://users.ece.utexas.edu/~adnan/pike.html
======
lower
> 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...](https://shreevatsa.wordpress.com/2008/05/16/premature-optimization-
is-the-root-of-all-evil/)

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

------
jacquesm
Link change?

[http://users.ece.utexas.edu/~adnan/pike.html](http://users.ece.utexas.edu/~adnan/pike.html)

~~~
dang
Yes. Changed from [http://blog.codonomics.com/2017/09/rob-pikes-5-rules-of-
prog...](http://blog.codonomics.com/2017/09/rob-pikes-5-rules-of-
programming.html).

It's also a dupe:
[https://hn.algolia.com/?query=pike%20rules&sort=byDate&dateR...](https://hn.algolia.com/?query=pike%20rules&sort=byDate&dateRange=all&type=story&storyText=false&prefix=false&page=0)

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

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

------
sirkarthik
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 :-/

------
1_2__4
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.

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

~~~
discoursism
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.

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

------
NTDF9
"Premature optimization is the root of all evil."

Except in an interview ;)

------
zebraflask
Sound principles, as usual.

------
khanjahanzaib27
That is pretty nice topic.

