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

161–170 of 332 posts

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

#161

Post by paulryanrogers »

dkarl wrote: post #126

> 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. I wish people would follow this rule and just let stuff work. I recently encountered the most extreme version of this I've ever seen in my career: a design review where a guy proposed a Redis caching layer…

Never read the release notes for MySQL. Unless phrases like "server exit" or 'regression' don't bother you.

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

#162

Post by YarickR2 »

flukus wrote: post #151
maxk42 wrote: post #133

Earlier quoted context omitted.

This is particularly exasperating for me. I can't tell you how many times in my professional career I've ended up speeding up systems by removing two or three layers of improperly-implemented "caching" and using good ol' MySQL and a basic understanding of algorithmic time complexity to simplify things.

Me too. I've seen a few systems that replaced their simple request requiring 10,000 queries "optimized" by requiring 10,000 cache lookups when they should have just added some joins. The bottleneck is the network latency, not the database. The worst I've seen is an nHibernate cache stored in a session variable, half the database was being serialized/deserialized on every http request. Fortunately that was a small dat…

It very much depends. I've seen too many cases when business logic was moved to the database layer, with absolutely disastrous effects. Scaling application backends doing map-reduce on a pre-filtered datasets is way easier than scaling database to handle five-way joins. Yet,I've seen opposing cases too, when rdbms was used as a huge key-value storage , and was pushing hundreds of thousands of rows to tens of backends, sucking it's bandwidth dry.

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

#163

Post by glangdale »

These rules are good as far as they go. However, they are notably silent on what happens when they stop working.

If you're a celebrity computer scientist and a problem has been 'squashed' to the point where there aren't any more 80-99% "hot spots" I guess you can just parachute out of there and on to a more interesting problem.

However, if you're paid to work on a particular thing, sooner or later, you will fire up a profile and say "oh, great, I don't have a hot spot anymore, just a bunch of 10-30% 'warm spots'". At that point you need to attack problems that aren't traditional bottlenecks if you still want to get speedups.

Moreover, the things that you learn from repeatedly attacking those 10-30% 'warm spots' might be fundamentally different from the learning you get from, I dunno, taking some O(N^2) monstrosity out of the "99% of the profile" and Declaring Victory.

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

#164

Post by renewiltord »

mplewis wrote: post #137
renewiltord wrote: post #68

Earlier quoted context omitted.

Read The Goal by Eliyahu Goldratt. While it's possible your founder came upon the idea independently, this is one of many that are repeated in that book. It's relatively short and entertaining to read and has definitely survived the 36 years since first publishing quite well.

This was adapted into a novel about IT/devops called The Phoenix Project. It's an excellent read.

I second this. Quite the entertaining read, honestly. I also enjoyed the completely unnecessary transformation of the security dork into a security ubermensch.

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

#165

Post by TeMPOraL »

dkarl wrote: post #126

> 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. I wish people would follow this rule and just let stuff work. I recently encountered the most extreme version of this I've ever seen in my career: a design review where a guy proposed a Redis caching layer…

That case you've seen speaks of the guy's inexperience and lack of understanding.

I have a problem with this rule because what I see happening is people taking it to heart and no longer thinking about what they're doing performance-wise. And then the program is working 1000x slower than it should, at no extra gain (and often a loss) of readability or safety, just because someone decided to use O(n) data structure where O(1) would do, or keeps repeating the same computation thousand times instead of ensuring it's done once.

So to your "let stuff work", I want to also add: "understand the work you're putting the computer through", and "don't do stupid things".

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

#166

Post by jonfw »

chrisweekly wrote: post #92
jonfw wrote: post #2

"Write stupid code that uses smart objects" That's a good one. It's amazing how much complexity can be created by using the wrong abstractions.

Yes! We should replace DRY (don't repeat yourself) with AHA (avoid hasty abstractions), as the dominant rule of thumb.

It's key to write code that can be easily re-factored, because most of the time you come up with a much better idea a week later.

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

#167

Post by zimpenfish »

dkarl wrote: post #126

> 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. I wish people would follow this rule and just let stuff work. I recently encountered the most extreme version of this I've ever seen in my career: a design review where a guy proposed a Redis caching layer…

> a Redis caching layer and a complex custom lookup scheme

Bane of my life. A few gigs ago, they had a global Redis cache, a Redis cache per server, an in-app cache, and then MySQL. Needless to say, there were many, MANY bugs that came down to cache coherency and race conditions between them.

[edit: it was a global Redis, not clustered.]

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

#168

Post by peteradio »

tjalfi wrote: post #142
NewEntryHN wrote: post #42

Earlier quoted context omitted.

You made an optimization for the future when enough bottlenecks have been fixed such that this one part becomes the bottleneck.

There are several assumptions that are far from a given with premature optimization. 1. Adding the optimization didn’t make the code more complicated. 2. Adding the optimization didn’t introduce a bug. 3. This part of the code will be a bottleneck in the future. The time spent optimizing is a write-off if the project is canceled or that portion is replaced.

All, true, but if you have a time budget and you know this thing will prevent you from meeting it AND making this change now will inform the architecture then its the right optimization to make.

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

#169

Post by hckr1292 »

zimpenfish wrote: post #167
dkarl wrote: post #126

> 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. I wish people would follow this rule and just let stuff work. I recently encountered the most extreme version of this I've ever seen in my career: a design review where a guy proposed a Redis caching layer…

> a Redis caching layer and a complex custom lookup scheme Bane of my life. A few gigs ago, they had a global Redis cache, a Redis cache per server, an in-app cache, and then MySQL. Needless to say, there were many, MANY bugs that came down to cache coherency and race conditions between them. [edit: it was a global Redis, not clustered.]

Did we both work at a certain edtech company? Seems oddly specific and exactly how I remember our monolith being structured

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

#170

Post by [deleted] »

mgkimsal wrote: post #93
monocasa wrote: post #71

Earlier quoted context omitted.

Resaid by Linus with a bit more modern nomeclature (and Linus's trademark bluntness): > Bad programmers worry about the code. Good programmers worry about data structures and their relationships

> Bad programmers worry about the code And yet, I see a whole swath of the industry hyper-focused on various linters/styling/rules.

[deleted]
Post reply on HN