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

Rob Pike’s Rules of Programming (1989)

cs.unc.edu

Post reply on HN
Print view View original

381–390 of 483 posts

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

#381

Post by IshKebab »

imjonse wrote: post #190
anymouse123456 wrote: post #93

There are very few phrases in all of history that have done more damage to the project of software development than: "Premature optimization is the root of all evil." First, let's not besmirch the good name of Tony Hoare. The quote is from Donald Knuth, and the missing context is essential. From his 1974 paper, "Structured Programming with go to Statements": "Programmers waste enormous amounts of time thinking about,…

I was a bit worried you are paraphrasing Rob Pike, but no, he actually agrees with that Knuth quote. I am almost certain that people building bloated software are not willfully misunderstanding this quote; it's likely they never heard about it. Let's not ignore the relevance of this half a century old advice just because many programmers do not care about efficiency or do not understand how computers work. Premature…

No I've definitely heard plenty of people use this as some kind of inarguable excuse to not care about performance. Especially if they're writing something in Python that should really be not super slow. "It's fine! Premature optimisation and all that. We'll optimise it later."

And then of course later is too late; you can't optimise most Python.

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

#382

Post by O3marchnative »

quietbritishjim wrote: post #378
dgb23 wrote: post #318

Earlier quoted context omitted.

It's also notable that video games are programs that run for hours and iterate over large sets of very similar entities at 60 frames or more per second repeatedly and often do very similar operations on each of the entities. That also means that "just do an array of flat records" is a very sane default even if it seems brutish at first.

I think when he said "just do an array of flat records" he meant as opposed to record of arrays (i.e. row oriented vs column oriented), as opposed to fancy data structures which I think you're assuming he was implying. Separate arrays for each data member are common in game engines exactly because they're good for iterating over, which as you said is common.

That's also great for letting the compiler unlock auto-vectorization opportunities without delving into the world of manual SIMD.

Even storing something simple such as an array of complex numbers as a structure of arrays (SoA) rather than an array of structures (AoS) can unlock a lot of optimizations. For example, less permutes/shuffles and more arithmetic instructions.

Depending on how many fields you actually need when you iterate over the data, you prevent cache pollution as well.

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

#383

Post by IshKebab »

pydry wrote: post #159
twoodfin wrote: post #117

Earlier quoted context omitted.

Ignoring optimization opportunities until you see the profile only works when you actually profile! Profiling never achieved its place in most developers’ core loop the way that compiling, linting, or unit testing did. How many real CI/CD pipelines spit out flame graphs alongside test results?

I usually defer this until a PM does the research to highlight that speed is a burning issue. I find 98% of the time that users are clamoring to get something implemented or fixed which isnt speed related so I work on that instead. When I do drill down what I tend to find in the flame graphs is that your scope for making performance improvements a user will actually notice is bottlenecked primarily by I/O not by code…

The problem with ignoring performance is that you'll always end up with slow software that is awful to use but ticks all the feature boxes. As soon as someone comes along that is fast and nice people will switch to that.

People don't ask for software to be fast and usable because it obviously should be. Why would they ask? They might complain when it's unusably slow. But that doesn't mean they don't want it to be fast.

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

#385

Post by cjwoodall »

danielmarkbruce wrote: post #362
Jensson wrote: post #349

Earlier quoted context omitted.

Rule 3 was true 1989, back then computers were so slow and had barely any ram so most things you did only was reasonable for small number of inputs. Today we almost always have large amounts of inputs so its different.

This very much depends on where you work... and basically isn't true for most people. It's extremely true for some people.

Rule 3 is still very much real. Fancy fast algorithms often have other trade-offs. The best algorithm for the job is the one that meets all requirements well... Big-O is one aspect, data is another, determinism of the underlying things that are needed (dynamic memory allocation, etc) can be another.

It is important to remember that the art of sw engineering (like all engineering) lives in a balance between all these different requirements; not just in OPTIMIZE BIG-O.

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

#386

Post by senderista »

IvyMike wrote: post #373

Once upon a time in the 90's I was at work at 2am and I needed to implement a search over a data set. This function was going to be eventually called for every item, thus if I implemented it as a linear search, it would be n^2 behavior. Since it was so late and I was so tired, I marked it as something to fix later, and just did linear search. Later that week, now that things were working, I profiled the n^2 search. T…

For small enough n, linear search might have been faster.

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

#387

Post by senderista »

silisili wrote: post #324
ryguz wrote: post #297

[flagged]

> In practice what I see fail most often is not premature optimization but premature abstraction This matches my experience as well. Someone here commented once that abstractions should be emergent, not speculative, and I loved that line so much I use it with my team all the time now when I see the craziness starting.

“Abstractions should be written in blood”

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

#388

Post by [deleted] »

senderista wrote: post #386
IvyMike wrote: post #373

Once upon a time in the 90's I was at work at 2am and I needed to implement a search over a data set. This function was going to be eventually called for every item, thus if I implemented it as a linear search, it would be n^2 behavior. Since it was so late and I was so tired, I marked it as something to fix later, and just did linear search. Later that week, now that things were working, I profiled the n^2 search. T…

For small enough n, linear search might have been faster.

[deleted]

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

#390

Post by eikenberry »

alain94040 wrote: post #285
ta20211004_1 wrote: post #104

Can't agree more on 5. I've repeatedly found that any really tricky programming problem is (eventually) solved by iterative refinement of the data structures (and the APIs they expose / are associated with). When you get it right the control flow of a program becomes straightforward to reason about. To address our favorite topic: while I use LLMs to assist on coding tasks a lot, I think they're very weak at this. Cla…

Agreed, in my experience, rule 5 should be rule 1. I think I also heard it said (paraphrased) as "show we your code and I'll be forever confused, show me your database schema and everything will become obvious". Having implemented my shared of highly complex high-performance algorithms in the past, the key was always to figure out how to massage the raw data into structures that allow the algorithm to fly. It require…

I don't think they were ever meant to be in order of importance.
Post reply on HN