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

81–90 of 332 posts

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

#81

Post by OliverJones »

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 programmers will curse your name.

Keep your data structures simple enough to adapt to the future. Written another way: respect the programmers who have to use your data when you're not around to explain it.

And, a rule that's like the third law of thermodynamics. You can never know when you're designing data how long it will last. Written another way: your kludges will come back to bite you in the xxx.

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

#82

Post by dang »

If curious see also

2017 https://news.ycombinator.com/item?id=15265356,

https://news.ycombinator.com/item?id=15776124

2014 https://news.ycombinator.com/item?id=7994102

Pete_D gets credit for the date: https://news.ycombinator.com/item?id=15266498. These rules come from "Notes on Programming in C" (http://www.lysator.liu.se/c/pikestyle.html), which has its own sequence of threads:

2017 https://news.ycombinator.com/item?id=15399028,

https://news.ycombinator.com/item?id=13852734

2014 https://news.ycombinator.com/item?id=7728084

2011 https://news.ycombinator.com/item?id=3333044

2010 https://news.ycombinator.com/item?id=1887442

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

#83

Post by gentleman11 »

> Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident

What does this have to say about the careers and roles of data scientists vs programmers? A data scientists entire job is to categorize and model data in a useful way. In the future, will they fundamentally more important than coders, or will the two roles just merge?

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

#84

Post by screye »

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

as someone in ML, I see myself wanting the opposite.

ML researchers drown their algorithms in huge tables of results, effectively spending time on "how well" rather than the "what".

It often leads to things being added as long as they are better, with the conclusion of it being a gargantuan monster of models and hand-engineered changes. All with no one understanding how the whole things works as a single unit.

Flow charts are incredibly effective as the top most layer of abstraction. Does the whole process, when viewed in an end-2-end manner, make sense ? We dive into the details only if it passes that sniff test of a flow chart.

I might be missing the point being made here, but they can claw flowcharts from my cold dead hands.

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

#85

Post by gridlockd »

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, because if he did, he would've found that you need to think about performance right from the beginning and all the way during development, because making bad decisions early on can force you to rewrite almost everything.

For instance, if you start writing a Go program with the mindset that you can just heap-allocate all the time, the garbage collector will eventually come back to bite you and the "bottleneck" will be your entire codebase.

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

#86

Post by veets »

Supermancho wrote: post #65
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 webse…

It seems you are arguing something different, although I am having a hard time understanding what you have written. I think you are saying algorithms and data structures aren't hard, distributed systems are hard. In my experience choosing the correct data structures and algorithms in your services/programs/whatever can dramatically simplify the design of your systems overall.

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

#87

Post by lmkg »

mywittyname wrote: post #11

> "write stupid code that uses smart objects". Writing stupid code is actually really difficult. For me, it takes a little bit of iterating before I know just the right place to insert stupid.

I'm reminded of the old adage "I'm writing you a long letter, because I don't have time to write a short one."

(Often attributed to Mark Twain, but similar sentiments were expressed by many before him.)

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

#88

Post by chrisweekly »

dexen wrote: post #80
rubyn00bie wrote: post #77

> 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. That one hits me in the feels because I think a lot of folks focus on algorithms (including myself), and code patterns, before their data and as a result a lot of things end up being harder than they need to be.…

It's worth noting the same holds true for UI: data dominates. Design your widgets, layout, and workflow around the data.

Amen. My 23 years experience in webdev says React (the paradigm, not the lib per se) is dominating web UI precisely because it is all about unidirectional data flow.

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

#89

Post by algebra-history »

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?

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

#90

Post by mathattack »

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

An early mentor put it as “learn the data, which won’t change, before learning the fancy stuff on top, which will”

That carried me very well.

Post reply on HN