Rob Pike’s Rules of Programming (1989) • Hacker News Board

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

#71

Post by monocasa » Wed, Aug 12, 2020, 8:28 PM UTC

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

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

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

#72

Post by lliamander » Wed, Aug 12, 2020, 8:29 PM UTC

dllthomas wrote: post #59

lliamander wrote: post #44

Earlier quoted context omitted.

Yep. And if what you have is an Abelian Group, then you also get distributed computation as well (thanks to commutativity).

While true, that's too strict. An Abelian group (like any group) needs inverses. You get distributed computation if you've got an Abelian semigroup.

Thanks for the correction. I think that in Avi Bryant's talk (that I linked to above) Stripe ended up using Abelian groups for some reason, rather than Abelian semigroups, though if so I forget the reason why.

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

#73

Post by [deleted] » Wed, Aug 12, 2020, 8:30 PM UTC

dogbox wrote: post #69

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

[deleted]

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

#74

Post by tinco » Wed, Aug 12, 2020, 8:30 PM UTC

svec wrote: post #43

Pike himself says "there's a 6th rule": https://twitter.com/rob_pike/status/998681790037442561?lang=... (6. There is no Rule 6.) And points to the best source he finds for it on the web: http://doc.cat-v.org/bell_labs/pikestyle

dang if this sticks to the frontpage, can you change the title to "Rob Pike's 5 rules of programming in C"? As the title is now it misrepresents Rob Pikes words.

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

#75

Post by gnulinux » Wed, Aug 12, 2020, 8:31 PM UTC

lliamander wrote: post #44

kens wrote: post #39

Earlier quoted context omitted.

In case you've wondered what a monoid is, that's a monoid. Something with an associative operation (and an identity), so you can do the operation on chunks in parallel, like addition.

Yep. And if what you have is an Abelian Group, then you also get distributed computation as well (thanks to commutativity).

You can distribute the computation on just a monoid as well but it needs more bookkeeping. In particular, your reduce function should know

* lhs is before rhs

* There is no data between lhs and rhs

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

#76

Post by dllthomas » Wed, Aug 12, 2020, 8:31 PM UTC

lliamander wrote: post #72

dllthomas wrote: post #59

Earlier quoted context omitted.

While true, that's too strict. An Abelian group (like any group) needs inverses. You get distributed computation if you've got an Abelian semigroup.

Thanks for the correction. I think that in Avi Bryant's talk (that I linked to above) Stripe ended up using Abelian groups for some reason, rather than Abelian semigroups, though if so I forget the reason why.

Inverses don't show up as much as I'd (aesthetically?) like in computing. There was an interesting application here: https://www.reddit.com/r/haskell/comments/9x684a/edward_kmet...

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

#77

Post by rubyn00bie » Wed, Aug 12, 2020, 8:33 PM UTC

> 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. I've always liked this quote from Torvalds on the subject speaking on git's design (first line is for some context):

> … git actually has a simple design, with stable and reasonably well-documented data structures.

then continues:

> In fact, I'm a huge proponent of designing your code around the data, rather than the other way around, and I think it's one of the reasons git has been fairly successful […] I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships.

When I have good data structures most things just sort of fall into place. I honestly can't think of a time where I've figuratively (or literally) said "my data structure really whips the llamas ass" and then immediately said "it's going to be horrible to use." On the contrary, I have written code that is both so beautiful and esoteric, its pedantry would be lauded for the ages-- had only I glanced over at my data model during my madness. No, instead, I awaken to find I spent my time quite aptly digging a marvelous hole, filling said hole with shit, and then hopping in hoping to not get shitty.

One thing that really has helped me make better data structures and models is taking advanced courses on things like multivariate linear regression analysis specifically going over identifying things like multicolinearity and heteroskedasticity. Statistical tools are incredibly powerful in this field, even if you aren't doing statistical analysis everyday. Making good data models isn't necessarily easy, nor obvious, and I've watched a lot of experienced folks make silly mistakes simply because they didn't want something asinine like two fields instead of one.

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

#78

Post by dllthomas » Wed, Aug 12, 2020, 8:35 PM UTC

gnulinux wrote: post #75

lliamander wrote: post #44

Earlier quoted context omitted.

Yep. And if what you have is an Abelian Group, then you also get distributed computation as well (thanks to commutativity).

You can distribute the computation on just a monoid as well but it needs more bookkeeping. In particular, your reduce function should know * lhs is before rhs * There is no data between lhs and rhs

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

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

#79

Post by atombender » Wed, Aug 12, 2020, 8:37 PM UTC

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.

Not all optimization candidates are about bottlenecks. Reducing allocation is also optimization, for example.

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

#80

Post by dexen » Wed, Aug 12, 2020, 8:38 PM UTC

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.