
Rob Pike's Rules of Programming - torb
http://users.ece.utexas.edu/~adnan/pike.html
======
hnkain
I don't think the author's interpretation of #5 to mean use smart objects
(which I'll guess means objects in the object-oriented sense) is correct. I
interpret Pike's meaning to be to use dumber objects that make the data
visible and obvious. That's also consistent with Go's emphasis on simple
datatypes.

It's very close (in my opinion) to a restatement of Brook's quote "Show me
your flowcharts and conceal your tables, and I shall continue to be mystified.
Show me your tables, and I won’t usually need your flowcharts; they’ll be
obvious."

~~~
derefr
No, it doesn't mean objects in the object-oriented sense. It means something
more like "don't build an array and then iterate through it to get the minimum
item, if you could just build a minheap." I.e., if you can, use data
structures that do the heavy lifting of your algorithms "for free."

~~~
wging
Total tangent, but it occurs to me that if all you want is the minimum item,
you maybe don't even need a minheap. You can just keep a single item--the
smallest--and replace the operation of adding to the array with the operation
of compare-and-possibly-replace.

~~~
AgentME
As long as you don't need to remove items or update their costs often.

------
zmmmmm
I feel torn about the "premature optimization" stuff. On the one hand it's
clearly true that we're terrible at predicting bottlenecks and it makes no
real sense to second guess them at any fine level of detail. On the other
hand, I think about products that I love to use and they are all fast. I think
about the first iPhone and how utterly crucial that first user experience was.
Did they achieve that by just writing giant gobs of code and then circling
back afterwards to fix a few hotspots? I think about how Chrome was such a
delight after FireFox got slower and slower and more bogged down. Clearly,
Chrome was written from the ground up to avoid that. I am not so sure you can
really optimise for performance after the fact, at least not universally.
There are times when you have to build it into the very fabric of a project
right from the start. Once a project has a giant mass of moderately slow code,
there's nothing you can do except rewrite it to get better performance.

~~~
d23
To me premature optimization goes far beyond just speed: it's a judgment call,
and it affects everything we do as programmers.

Should I spend more time here making this variable readable? Should I
structure this script to be maintainable, or is it going to be of no use in 2+
weeks?

Sometimes the answer is yes; sometimes the answer is no. The key is not to
_pre_ -maturely optimize. You have to use your own good judgment and an
iterative problem solving process to figure out what the metaphorical bottle
neck is and fix it (I say metaphorical because, again, it's not just about
speed).

~~~
zmmmmm
Yes - I think this is what I was trying to express. I guess I think the
message about premature optimization is much more subtle than usually
accounted for. It's about decisions to introduce complexity, to sacrifice
design integrity, etc. in favour of performance.

But it is not about devaluing having a careful discipline and intuitive sense
of the performance of code and a rigour about how you think about performance
in your work. All those things are still incredibly important.

------
rob_rasmussen
This list is from Rob's "Notes on Programming on C", written 25 years ago:
[http://doc.cat-v.org/bell_labs/pikestyle](http://doc.cat-v.org/bell_labs/pikestyle)

Worth reading for some context.

------
toolslive
"Premature optimization is the root of all evil" I always thought this was a
Knuth quote.

[http://c2.com/cgi/wiki?PrematureOptimization](http://c2.com/cgi/wiki?PrematureOptimization)

seems to concur.

~~~
pbsd
From [1], page 8:

    
    
      There is no doubt that the grail of efficiency leads to abuse.
      Programmers waste enormous amounts of time thinking about, or worrying
      about, the speed of noncritical parts of their programs, and these
      attempts  at efficiency actually have a strong negative impact when
      debugging and maintenance are considered. We should forget about small
      efficiencies, say about 97% of the time: premature optimization is the
      root of all evil.
      
      Yet we should not pass up our opportunities in that critical 3 %. A
      good programmer will not be lulled into complacency by such reasoning,
      he will be wise to look carefully at the critical code; but only after
      that code  has been identified. It is often a mistake to make a priori
      judgments about what parts of a program are really critical, since the
      universal experience of programmers who have been using measurement
      tools has been  that their intuitive guesses fail. After working with
      such tools for seven years, I've become convinced that all compilers
      written from now on should be designed to provide all programmers with
      feedback indicating  what parts of their programs are costing the
      most; indeed, this feedback should be supplied automatically unless it
      has been specifically turned off.
    

[1]
[http://cs.sjsu.edu/~mak/CS185C/KnuthStructuredProgrammingGoT...](http://cs.sjsu.edu/~mak/CS185C/KnuthStructuredProgrammingGoTo.pdf)

~~~
ivan_ah
The "indicating what parts of their programs are costing the most" made me
think of the color scheme when working in cython: white (C-fast), yellow
(slow).
[http://docs.cython.org/src/quickstart/cythonize.html#determi...](http://docs.cython.org/src/quickstart/cythonize.html#determining-
where-to-add-types)

of course it doesn't tell you anything about the speed of the C code, but I
find the line coloring to be a nice UI for showing computational cost.

------
z3t4
I think what happens with all intermediate or senior programmers is that we
start to think about the best solution instead of just getting the job done.

Most code we write will either not be used or eventually rewritten anyways.

~~~
zmmmmm
> Most code we write will either not be used or eventually rewritten anyways.

But it's like the advertsing paradox: we know most of our code will be
discarded or rewritten, but we don't know which parts won't. And even worse,
it is often the bad parts that survive because people become afraid to touch
them.

~~~
TeMPOraL
We're screwing ourselves badly with that attitude in the long term. Because of
similar attitudes in setting up industrial contro systems, you can now shut
down an entire factory with a misplaced ICMP ping. Layers of hacks built on
layers and layers of other hacks will bite us hard at some point, and I mean
in the "lives lost" sense of biting.

------
jonahx
Anyone have good before and after examples of Rule 5? That is, a "dumb" data
structure with "smart" code refactored to a smart data structure with dumb
code?

~~~
nmrm
I don't have actual code. But when tutoring CS1 and CS2 students during
undergrad, it was common for students to try to implement algorithms in terms
of linked lists when they should have been using a tree.

The really persistent students would get things to almost work -- often with
hundreds or thousands of lines for something that, with a tree, doesn't take
more than 10-50 lines.

This is also an interesting case study in human behavior; the students were
typically too impatient to spend 20 minutes thinking about the problem before
coding, but could spend 20-30 hours on a single assignment. Odd combination of
work ethic and lack of patience...

~~~
derefr
> the students were typically too impatient to spend 20 minutes thinking about
> the problem before coding, but could spend 20-30 hours on a single
> assignment. Odd combination of work ethic and lack of patience...

I wouldn't call it a lack of _patience_ , per se. In most modern models of the
brain, exercising executive control to think abstractly ("using System 2")
expends energy for as long as you're doing it, and the explanation for many of
the brain's inherent shortcuts and biases is to to prevent you from switching
into System 2 for longer than absolutely necessary.

I have a feeling that a large part of what is characterized as "intelligence"
is simply the brain being willing, for whatever reason, to switch into System
2 "mode" more often, and stay in it for longer.

~~~
ivan_ah
In case anyone else is wondering, System 1 = autopilot thinking and System 2 =
deliberate thinking.

From Thinking, Fast and Slow by Daniel Kahneman

~~~
judk
Kahneman chose the names "1" and "2" because he asserts that those names are
easier to remember than "autopilot" and "deliberate", and so don't require
System 2 thinking when you use them. I find that the confusion arouns these
names undermines Kahneman's theory, as seen in this thread.

------
deathanatos
> Rule 3. Fancy algorithms are slow when n is small, and n is usually small.
> Fancy algorithms have big constants. Until you know that n is frequently
> going to be big, don't get fancy. (Even if n does get big, use Rule 2
> first.)

Thing is, I _don 't_ know; n is definitely small in our unit tests, but if it
isn't guaranteed¹ to be small, I'd rather start the code off as something with
O(decent) as opposed to O(whatever an array gets me). It's not clear to me if
this is what Rob Pike means though: does simply using a hashtable when
appropriate to avoid iterating through a list count as "fancy"?

When the ultimate bounds of n aren't certain, I'd rather start with a good
O(...) algorithm, and _then_ apply the "measure, and optimize."

¹and even then, if my "guarantee" is coming from something other than physics,
I'm wary.

~~~
bcbrown
If you can get a naive n^2 solution, or build a complicated nlgn solution, and
you know the size of the data will be ~100 items, certainly never >1000
solutions, I'd choose the naive solution.

Edit: and it's not in the middle of a tight loop

------
ChrisAntaki
This is great advice. What I take away from it is, keep it simple, keep it
readable, and save the detailed optimization for later, when you have time to
really test and measure it.

------
sreitshamer
Data live much longer than programs.

~~~
emmelaich
Exactly!

Make the format simple and obvious enough to be applicable for a wide range of
purposes. Because humility.

[http://keithp.com/blogs/Repository_Formats_Matter/](http://keithp.com/blogs/Repository_Formats_Matter/)

On-the-wire formats matter, on-disk formats matter.

------
buckbova
This shouldn't replace understanding the problem domain and carefully planning
before tackling a moderate to large scale project. Yes, one shouldn't tune
each individual piece with unjustified optimization but the high level design
should be thoughtfully laid out prior to hammering out large swaths of code.

Too many developers plow forward in a brute force manner creating unmanageable
inconsistent messes and use rules like these to justify their lousy (lack of)
design choices.

My rules:

1\. Understand the problem domain.

2\. Design flexible solution using common patterns.

3\. Stub out skeleton of system encompassing majority of specs.

4\. Revisit design and consider all conceivable exceptions and outlier and
tweak design as necessary.

5\. Review above work with others and tweak design further as necessary.

6\. Coding.

~~~
d23
> Design flexible solution using common patterns.

Maybe this is part of the problem. I'm relatively young, so I've only seen a
few design patterns, but it'd be interesting to have a high-level look at some
of the most common patterns and what they're good at and what they aren't. For
instance, I've never really used a messaging queue, but it seems like a genius
design for a particular type of problem. I wonder how many other designs are
out there that I'm not using, instead opting to shoe-horn in my existing ways
of thinking.

~~~
optymizer
Just in case, here's the 'Gang of Four' book on design patterns:
[http://www.amazon.com/Design-Patterns-Elements-Reusable-
Obje...](http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-
Oriented/dp/0201633612)

------
vram22
I like Rule 6. Nearly but not 100% sure that it is from another version of
this same list by Rob Pike, that I read somewhere else:

Rule 6. There is no Rule 6.

------
kilon
I have one rule , "pray .... non stop"

------
actualal
Can be distilled into a one liner. "NO DRUM SOLOS"

------
rakeshmenon
Pre-optimization is one of the biggest problems with today's programmers.
First priority should always be releasing the software. Let it break. Make
optimizations when and where necessary.

No one can look into the future.

~~~
jlouis
First priority is about modularity and elegance. An elegant program is often
fast, correct and with a short time-to-market.

It is the numerous scores of small hacks that bogs down programmers nowadays.

~~~
rakeshmenon
When I say first priority is releasing the software - it means releasing
software that works functionally. We cant optimize stuff which we are not sure
will even break due to performance issues.

Analyze traffic/usage of parts of the application - mark areas which are used
most - analyze performance - optimize if not up to mark.

If stress is always on elegant code - it'll always end up taking more time. In
real-life scenario, no module is ever "bug-free". The cases change from day to
day. When you're absolutely sure that the functionality is exactly what is
required - then you should spend time optimizing it.

------
evidencepi
That's why I trust golang.

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

Quite ironic coming from the creator of Go. Algebraic data types, anyone?

~~~
tptacek
Oh, interesting. It's the middlebrow dismissal. I thought it had become an
endangered species, but here it is, stepping right out into a crowded thread
and trying to take out Rob Pike of all people. Good show!

[https://news.ycombinator.com/item?id=4692598#up_4693920](https://news.ycombinator.com/item?id=4692598#up_4693920)

~~~
anon1385
Of course pg hates the "middle brow" dismissal. Part of his schtick is Malcolm
Gladwell style 'intellectual porn' essays that ignore facts and complexity to
paint an aesthetically pleasing (but false) narrative to people who are not
subject experts. At this stage I'm not sure if PG does it deliberately like
Gladwell admitted doing. I'm willing to give him the benefit of the doubt and
say he does it inadvertently by writing about topics where he has no knowledge
of previous study, coupled with a large ego born of being rich and constantly
surrounded by sycophants trying to get funding.

The middle brow dismissal is apt/damaging in these situations because it saves
everybody a lot of time by quickly demonstrating that the author ignored those
pesky real world facts and complexities that spoilt the ideological narrative.

