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

61–70 of 332 posts

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

#61

Post by dragontamer »

krzat wrote: post #45
dragontamer wrote: post #22

Earlier quoted context omitted.

> Am I wrong to avoid writing O(n^2) code if at all possible when it is fairly easy to use hash tables for a better time complexity Are you sure that std::unordered_map is faster than std::vector? Did you measure? Every time you access an element in std::vector, you also access nearby ones (thanks to L1 cache, as well as CPU-prefetching of in-line data). In contrast, your std::unordered_map or hash-table has almost n…

Worrying about performance of small collections is premature optimization. Using maps or sets nowadays is mostly for clarity, as they are used to solve certain kind of problems.

I agree with you. But what you're talking about is completely different from what I was responding to originally.

If you need a set, use a set. But don't assume that its faster than a std::vector.

Even then, std::vector has set-like operations through binary_search or std::make_heap in C++, so it really isn't that hard using a sorted (or make_heap'd) std::vector in practice.

--------

Even if you don't plan on doing optimization work, its important to have a proper understanding of a modern CPU. The effects of L1 and prefetching are non-trivial, and make simple arrays and std::vectors extremely fast data structures, far faster than compared to 80s or 90s computers anyway. A lot of optimization advice from the past has become outdated because of the evolution of CPUs.

So its important to bring up these changes in discussion, from time to time, to remind others to restudy computers. Things change.

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

#62

Post by nix23 »

_urga wrote: post #52
nix23 wrote: post #47

Earlier quoted context omitted.

That's a bit broad i think, talking about pure speed of your task you are right, talking about energy consumption then it's not always the case. Or small but often repeated task should be optimized no mater if they are bottlenecks, when the system grows they will become bottlenecks, optimize like a Vulcan is what my boss once said...be logical and nothing else (my interpretation)

"optimize like a Vulcan"... classic!

Best boss ever!! He even had a bottle of his best whisky refilled in a bottle called "Saurian brandy", so everyone who said that this is illegal or ohh that's "start trek" got one...well not a bottle but a glas :)

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

#63

Post by _urga »

chubot wrote: post #46
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.

Except that there are infinite such non-bottlenecks, and all the effort you spend on there is effort not spent on the real bottlenecks. In other words, all engineering is time- and cost-constrained. Anybody can build a good chair for $10,000 or a good PC for $100,000. Doesn't mean it's good engineering.

"Anybody can build a good chair for $10,000 or a good PC for $100,000."

And some people can build a great PC for $1,000 that runs circles around the good PC for $100,000.

There's so much more to engineering than thinking in terms of time and cost constraints. Those are real constraints, but they're not the most important.

Engineering is design. If you have good design, good insight, you can do things that people with infinite time and budget could never dream to achieve. You can start making a product that's a hundred times more powerful for a tenth of the price in a fraction of the time. If you don't have good design, good insight, then no amount of time or budget can help you.

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

#65

Post by Supermancho »

Ozzie_osman wrote: post #8

It turns out rule 5 (Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident) is both true but also hard. Eric Evans' Domain Driven Design is a good book on the topic.

> If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident) is both true but also hard.

The problem is not the self-evident algorithm, but the delicate implementation (or god forbid, at scale).

Take in 1000 web requests per second. The data is all strictly validated and has about 60 fields a record/req plus dealing with errors.

How does that go from webserver to (rolls dice) kafka to a (rolls dice) cassandra that can be queried accurately and timely? How much does that cost?

Oh, that's not a programmer problem. Except it is. Creating a fantasy niche of describing problems as data vs algorithm is the canonical ivory tower disconnect.

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

#66

Post by RoutinePlayer »

commandlinefan wrote: post #49

> Tony Hoare's famous maxim "Premature optimization is the root of all evil." Actually that was Donald Knuth - it's an urban legend that it's an urban legend that it was originally Knuth. Hoare was quoting Knuth, but Knuth forgot he said it, and re-mis-attributed the quote to Hoare.

This reminds me of that Woody Allen joke about someone translating all the T.S. Eliot’s poems into English after some vandals had broken into the school library and translated them into French.

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

#67

Post by Areading314 »

These resonate, especially #1, but I'm not so sure about #5. Although it makes sense to choose good data structures, I don't think that guarantees a simpler algorithm. For example you can store your data in a heap (tree), and still need to write a tree traversal algorithm to print out the elements in order.

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

#68

Post by renewiltord »

sethammons wrote: post #19

A quote from one of our founders that I've always liked: If you make an optimization that was not at a bottleneck, you did not make an optimization.

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.

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

#69

Post by dogbox »

> Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.

Is "data structures" the correct term here? Assuming I'm not misinterpreting, the usage of "data structures" can be misleading - one usually thinks of things like BST's and hash tables, which are inherently tied to algorithms. I feel like "data modeling" better captures the intended meaning here.

Post reply on HN