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

261–270 of 332 posts

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

#261

Post by coldtea »

avasthe wrote: post #214
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 taken to other extreme many times. Example: Google Chrome codebase was allocating lot of std::string and also someone used a Set to check membership of single item. [1] I mean, if you say like this, many people don't even care about algorithm complexity. Doesn't help that people want to write Python in the monster that is C++. https://groups.google.com/a/chromium.org/forum/m/#!msg/chrom...

>and also someone used a Set to check membership of single item. [1]

Depending on where it was done (fast path or not), this could be just fine.

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

#262

Post by vikiomega9 »

algebra-history wrote: post #89
lliamander wrote: post #9

Rule 5 seems to mirror one of my favorite insights from Alexander Stepanov: > In 1976, still back in the USSR, I got a very serious case of food poisoning from eating raw fish. While in the hospital, in the state of delirium, I suddenly realized that the ability to add numbers in parallel depends on the fact that addition is associative. (So, putting it simply, STL is the result of a bacterial infection.) In other wo…

Recently I searched the Web, trying to find out the origin of monoids as an approach to distributed computing, and couldn’t find it. This quote is a great find for me! Is this the origin?

If you're thinking about map-reduce, the original Google paper talks about associativity.

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

#264

Post by OliverJones »

OliverJones wrote: post #81

In long-lived systems (systems that run for many years) it's almost impossible to choose the "right data structures" for the ages. The sources and uses of your data will not last nearly as long as the data itself. What to do about this? Two things: STORE YOUR TIMESTAMPS IN UTC. NOT US Pacific or any other local timezone. If you start out with the wrong timezone you'll never be able to fix it. And generations of progr…

People ask "why UTC"? Good question. Here's why:

You can always translate UTC to a local time in a given timezone. With IANA zoneinfo, you can do that correctly even for historical data in places where timezone rules changed in the past.

You can always calculate elapsed times correctly by taking differences between UTC timestamps. With local times you can't. Because daylight time transitions.

If you started with a local service, UTC lets you expand globally without explaining to your new customers why your timestamps are not in their timezones.

Daylight time transition days. Because daylight time.

Oddball daylight transition rules. Because Indiana USA, from the legislature that almost wrote a law declaring the value of π to be 22/7.

Because almost everybody will understand your decision, even after you're gone.

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

#265

Post by Cthulhu_ »

thdrdt wrote: post #237
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…

It is all about lack of knowledge because checking where the bottlenecks are is one thing. Knowing why they are there is another. A retailer app was very slow. The developers proposed a newer faster server with a newer Oracle version. Then I took a look at one of the slowest queries. Changed it so it could use the indexes in a better way and the query went from +20 to 0.7 seconds. The developers measured the query wa…

Sounds like ops vs dev (or DBA) right there; it does make sense to a point that ops would grow into that kind of behaviour, given that they can't really allocate resources into performance enhancements for software (especially if it's from an external party or off-the-shelf). To them it's a black box.

But if it's an in-house thing then there should be open communication lines. The SRE paradigm makes sense there, where I see a SRE as part dev, part ops. They can identify perf issues as a software problem and either fix it or send it back to the authors.

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

#266

Post by Cthulhu_ »

cvrjk wrote: post #231
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.

I had worked on an application that saw less than 100 writes per minute and about 1k reads per min and used a caching layer in front of the DB. Not only was the cache actually slowing us down, it was also inconsistent with the DB. Can't even begin to express the amount of lost dev time and productivity. We couldn't get rid of it, because someone above was convinced that we would need it to scale in the future.

There are only two hard things in computer science: naming things, cache invalidation, and off-by-one errors.

I'm trying to never implement any caching if I can help it. The database itself does caching already as well.

And if you DO need caching, keep your hands off of the application; add a cache layer in front, or between the application and the database. But don't invent it yourself.

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

#267

Post by Cthulhu_ »

userbinator wrote: post #208
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…

It seems that a subset of developers are somehow convinced that adding complexity is a good thing for performance and should be done first, when it should really be a last resort. Their usual rebuttal is "it's scalable " and other buzzword-laden phrases. I wonder if it's a form of "big data envy" or just regular "architecture astronautism".

Honestly, it's the other way around usually; simplicity is scalable. A stateless service talking to a database is fine. You can scale out the service, and scale up the database. It's even easier when you use a cloud provider, their relational database offerings can scale from a wordpress blog's database to enterprise scale, tens of thousands of transactions / second.

The problem is that it's boring, and there's a lot of developers that create work and complexity to make their own jobs interesting.

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

#268

Post by Akronymus »

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.

I do like to use a linter to make it easier readable. But yeah, most of the architecture actually is based on how you store/structure your data. Code is just a result of how you implement the data.

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

#269

Post by Aeolun »

projektfu wrote: post #196
TeMPOraL wrote: post #165

Earlier quoted context omitted.

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 whe…

Architecture is not optimization. This gets fuzzy with the decision to use caching, static generation, etc. Ideally, redis or memcached can be added when needed. It will require some changing of the app but hopefully in limited places. This rule a la Pike is about doing things like writing assembly or manually unrolling loops in noncritical parts of code. However, in some code, almost everything is on the critical pa…

Don’t worry, we’ll use serverless! So we can support an unlimited amount of transactions per second!

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

#270

Post by sethammons »

b0afc375b5 wrote: post #194
renewiltord wrote: post #164

Earlier quoted context omitted.

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

I've read The Goal and The Phoenix Project. While I did enjoy the stories, I'm uncertain, perhaps due to inexperience, what the main lesson/s are supposed to be. Anyone want to share their main takeaways from these books?

Reduce feedback cycles
Post reply on HN