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

151–160 of 332 posts

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

#151

Post by flukus »

maxk42 wrote: post #133
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…

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

Even with in memory caches I've seen systems grind to a halt by death of a thousand cuts, dictionary based entity attribute systems where each attribute is looked up individually. There seems to be a mentality that constant lookup == free lookup and devs don't seem to realize that constant * $bignumber == $biggerNumber. Caching shouldn't be granular.

Obligatory latency numbers every programmer should know: https://gist.github.com/jboner/2841832

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

#152

Post by lokar »

rumanator wrote: post #111
mgkimsal wrote: post #93

Earlier quoted context omitted.

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

> And yet, I see a whole swath of the industry hyper-focused on various linters/styling/rules. It seems to me that what you're actually seeing is an entire industry trying to eliminate all code-related issues, specially bike-shedding ones. This is patently obvious to anyone who was forced to waste their time in code review iterations discussing, say, where a brace should go and how many spaces someone should have add…

This. The point of the style guide, now reaching its best embodiment in clang-format, gofmt, and others, is that you don't want to waste time arguing about, or even considering for a moment the formatting of anything.

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

#153

Post by jacobsenscott »

Quekid5 wrote: post #148
rumanator wrote: post #111

Earlier quoted context omitted.

> And yet, I see a whole swath of the industry hyper-focused on various linters/styling/rules. It seems to me that what you're actually seeing is an entire industry trying to eliminate all code-related issues, specially bike-shedding ones. This is patently obvious to anyone who was forced to waste their time in code review iterations discussing, say, where a brace should go and how many spaces someone should have add…

This usually a good time to apply the When In Rome rule. Do not reformat needlessly, follow the code style of the code you're modifying. Done. (If multiple people are arguing back and forth in code review -- when following the WIR rule -- tell them about the WIR rule and that should settle it. If not, you have bigger problems in your team.)

Sort of. You shouldn't combine style and non-style changes in on change set. But if your project has mixed styles from file to file you should assimilate the locals over time, just as the Romans did. A consistent style has value.

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

#154

Post by gridlockd »

byronr wrote: post #149
gridlockd wrote: post #85

All this advice against "premature optimization" has created generations of programmers that don't understand how to use hardware efficiently. Here's the problem: If you profile software that is 100x slower than it needs to be on every level, there are no obvious bottlenecks . Your whole program is just slow across the board, because you used tons of allocations, abstractions and indirections at every step of the way…

> Rob Pike probably has never written a program where performance really mattered Rob Pike has written window system software which ran in what now would be called a "thin client" over a 9600 baud modem and rendered graphics using a 2MHz CPU. He probably knows a thing or two about performance tuning.

By "rendered graphics" you mean "place characters on screen"? If the bottleneck for that is a 9600 baud modem throughput, there's not a lot you need to optimize, even on a 2MHZ CPU.

Also, having programmed more constrained systems decades ago doesn't magically make you knowledgeable on performance on modern hardware with completely different capabilities. In fact, it's probably what causes you to develop a "computers are so fast now, no need to think about performance"-mindset, because everything you want to do could be done in an arbitrarily inefficient way on modern hardware. Performance doesn't matter to you anymore.

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

#155

Post by enahs-sf »

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…

Wholeheartedly agree. What you're describing is like the ideal mysql use case. Also, even the most basic next steps performance-wise will probably tithe you over well into the TBs of data. The headroom for mysql is quite a bit higher than most people think unless you're operating at facebook scale.

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

#156

Post by lliamander »

gnulinux wrote: post #107
dllthomas wrote: post #78

Earlier quoted context omitted.

One way of looking at it is that equipping our data with that bookkeeping gives us something that commutes.

Hmm sure, but it is not a requirement that your underlying algebraic structure should commute, so I think original phrasing was misleading. The bookkeeping allows you to commute a specific list of objects, even though the underlying operation is anti-commutative (i.e. exists a,b a.b != b.a). At the moment of computation, you can build a new structure that commutes by enumerating the data. I guess it's true that you n…

One of the ideas in the talk I link is how you can represent typically non-commutative data (like averages) in a data structure that does support commutative operations (numerator/denominator pair) and to take advantage of generic analytics infrastructure.

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

#157

Post by nizmow »

andrewl wrote: post #5

In The Mythical Man Month Fred Brooks said "Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious." I first read that on Guy Steele's site: http://www.dreamsongs.com/ObjectsHaveNotFailedNarr.html

I've recently started a job in a very complex business domain, but sadly they're using NoSQL for everything. I've known for a while about the technical tradeoffs of NoSQL, but until now I'd never experienced that the lack of expressiveness in the data store is a major obstacle to understanding what kind of data the code deals with and how it's related. The data's all there, but exploring it without a real schema is much more difficult.

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

#158

Post by codetrotter »

johnisgood wrote: post #130
s17n wrote: post #128

Earlier quoted context omitted.

Nobody was ever "forced to waste their time" on this stuff. I have a simple rule - I don't comment on other people's style, and if people comment on my style, I just go with their suggestions. Problem solved.

> I just go with their suggestions. Why though? I am not going to go with suggestions if they make the code less readable for me!

I think the whole world would benefit if we’d make it so that code formatting happened separately from what was committed. Then everyone could have their local checkouts formatted the way they wanted and there would be nothing to argue about in terms of coding style.

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

#159

Post by fizwhiz »

farhaven wrote: post #134
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…

Do you work at my company? Because I have a coworker that is always proposing _exactly_ that solution. No matter what issues the code has, for him its usage of MySQL is always "the worst moment". Asking for benchmark just gets a repeat of "our worst moment is MySQL and we can solve that with some NoSQL cache".

My dude's just trying to get a promo, I guarantee it.
Post reply on HN