Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rob Pike’s Rules of Programming (1989)

users.ece.utexas.edu

Post reply on HN
Print view View original

71–80 of 122 posts

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

#71

Post by JBiserkov »

gue5t wrote: post #25
drostie wrote: post #8

I think #5, which is probably going to be thought of as great wisdom for our age, is secretly an empty tautology. That is, my amateurish work in schemas and validating data structures and type systems has led me to think that there is a somewhat hard-to-see but extremely-important bijection between data structures and the control structures that consume them. (In many ways this is theoretically a non-issue as there a…

How is a for-loop not a fold?

A fold is usually restricted to a combining function of 2 arguments - accumulated-so-far and current item.

A for-loop's body has no such restrictions, it can access any number of neighbor elements if the algorithm so requires.

    a[i] = a[i-1] * a[i+1]

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

#72

Post by marcosdumay »

winterlight wrote: post #51
whack wrote: post #27

Rule 6: Every well-intentioned rule will be bastardized and used to justify horrible code. Foo: "Hey, this 10000-element collection, which we do repeated lookups on... why are we using a list and not a HashSet?" Bar: "Because lists are so much simpler than a HashSet. Let's just KISS" Foo: "But... doing repeated lookups on a 10k sized list is so much slower than just using a HashSet!" Bar: "Oh really? Have you profile…

Ironically, in that situation, using a list might end up being more efficient due to cache locality. Or not. That's why measuring is so important, since performance can be a very counterintuitive subject. Hard-data should always prevail over theory and guesswork.

If it's that bad, it should be easy to discover what is fastest.

But the way too common situation is that you look at a program under development and tell people "no way, that list will be too large to keep searching, you should design it around a hash set", and people reply something about premature optimization and keep going, then it gets released and is too slow to use so you get to rewrite all their code under pressure.

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

#73

Post by kccqzy »

khedoros1 wrote: post #47
hyperpape wrote: post #10

"Rule 1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is." Everything about reading this quote depends on what you think a "speed hack" is. Without practical agreement on that, you'll get a lot of people arguing past each other.

I'd say "a modification to the code designed to speed up that section of code". Are there other reasonable definitions? I thought it was pretty clear that the rule could be accurately paraphrased as "Don't optimize a section for speed until you're sure that's where it's needed."

I'd say "hack" implies there's some sort of trade off, perhaps in readability and portability or additional assumptions.

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

#74

Post by anarazel »

winterlight wrote: post #51
whack wrote: post #27

Rule 6: Every well-intentioned rule will be bastardized and used to justify horrible code. Foo: "Hey, this 10000-element collection, which we do repeated lookups on... why are we using a list and not a HashSet?" Bar: "Because lists are so much simpler than a HashSet. Let's just KISS" Foo: "But... doing repeated lookups on a 10k sized list is so much slower than just using a HashSet!" Bar: "Oh really? Have you profile…

Ironically, in that situation, using a list might end up being more efficient due to cache locality. Or not. That's why measuring is so important, since performance can be a very counterintuitive subject. Hard-data should always prevail over theory and guesswork.

"Lists", presumably referencing a linked list, have horrible cache locality. You were thinking of an array?

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

#75

Post by parenthephobia »

khedoros1 wrote: post #42
smegel wrote: post #36

Earlier quoted context omitted.

How is writing code that loops over a list simpler than calling: things.Get("key") ?

Your "Get" method hides complexity. It could be that it loops over a list, or that it hashes to find the bin, then loops over the list of items in the bin, or any of other dozens of other possible implementations. So the next question is "What's the implementation of the Get(key) method?" Or maybe "Why aren't you using your language's library methods to loop over that list?"

Is this really an explanation of why manually iterating over a list is simpler than just calling a method?

Get is simpler precisely because it hides the complexity.

> Or maybe "Why aren't you using your language's library methods to loop over that list?"

What makes those methods not subject to the "hiding complexity" objection?

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

#76

Post by punnerud »

A prox what was said in the book Rework; If we add 1000 more professors and expand to more cities Harvard/MIT/Stanford would be a better school. Everyone laught of this, why do we still think it is a good thing for a company? Start small, fix while you go and keep a customer focus (not growth focus in both company size and software complexity)

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

#77

Post by analog31 »

jonahx wrote: post #4

Torvalds version of rule 5: “Bad programmers worry about the code. Good programmers worry about data structures and their relationships.” Brooks's version: "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."

I wrote in Pascal for many years. Trust me, I can design data structures that will baffle the greatest scholars of the ages. ;-)

I found one of my old codes, a few months ago, and I'm still trying to figure out what possessed me to write it.

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

#78

Post by dang »

Pete_D wrote: post #39
dang wrote: post #35

I put 2007 above because it's the earliest year at https://web.archive.org/web/20070210233739/http://users.ece.... , but if someone has a better date for this we can change it.

https://www.lysator.liu.se/c/pikestyle.html includes the rules under the header "Complexity", and is dated 1989.

Wow, well done. Edited above.

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

#79

Post by glangdale »

Having spent a great deal of time - most of my career, really, doing performance optimization, some of this rings true, but much of it doesn't.

Rule 2 only applies if you can just decide that your current level of performance is "pretty great" and then parachute away to another project. Otherwise if you find that, instead of 1 hot spot taking 80% of your time, you have 5 warm spots taking 16% of your time, you have 5x as much thinking to do to fix your problems and get that potential 4x speedup (assuming you could get cut that 80% down by a factor of 16).

Rule 4 is an argument from bad implementation. It's harder to get fancy algorithms right, but what does it mean to say an algorithm is buggier than some other algorithm. Are we seriously meant to think that there are some bugs buried in Strassen's matrix multiply?

Rule 3 is dubious. It seems to imply that the performance cost of fancy algorithms on low N matters, which assumes that we are actually executing the algorithm quite a bit. Perhaps we've picked the wrong fancy algorithm? Maybe if you have a godzillion tiny matrix multiplies you shouldn't be using Strassen's but you might still get a performance win from doing something 'fancy' that's tuned for large numbers of small matrix multiplies...

As for Rule 5, this is probably the best of the lot. That's why I like to use languages that allow me to describe my data structures in detail... even going so far as to say that the contents of my user-built containers have types. Ahem.

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

#80

Post by whack »

winterlight wrote: post #51
whack wrote: post #27

Rule 6: Every well-intentioned rule will be bastardized and used to justify horrible code. Foo: "Hey, this 10000-element collection, which we do repeated lookups on... why are we using a list and not a HashSet?" Bar: "Because lists are so much simpler than a HashSet. Let's just KISS" Foo: "But... doing repeated lookups on a 10k sized list is so much slower than just using a HashSet!" Bar: "Oh really? Have you profile…

Ironically, in that situation, using a list might end up being more efficient due to cache locality. Or not. That's why measuring is so important, since performance can be a very counterintuitive subject. Hard-data should always prevail over theory and guesswork.

For any realistic workload containing a mix of failed-lookups, and lookup-hits midway through the list, we're talking about many thousands of comparisons for a single lookup on average. Regardless, replace list with linked-list in the above example, for illustrative purposes.

I agree that measurements & hard-data are preferable to guesswork, but it takes time and energy to gather these measurements and hard-data as well. For minor decisions where the alternative proposal is very slightly more complex, but there's a very compelling reason to assume order-of-magnitude performance improvements, I would argue that gathering data is a waste of time.

Post reply on HN