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

11–20 of 122 posts

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

#11

Post by wtetzner »

drostie wrote: post #8

I think #5, which is probably going to be thought of as great wisdom for our age, is secretly an empty tautology. That is, my amateurish work in schemas and validating data structures and type systems has led me to think that there is a somewhat hard-to-see but extremely-important bijection between data structures and the control structures that consume them. (In many ways this is theoretically a non-issue as there a…

I think the wisdom is that data structures are declarative. It's also much easier to build an image in your head of a data structure than an algorithm, because an algorithm is actions over time.

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

#12

Post by [deleted] »

dws wrote: post #9
avinassh wrote: post #5

> Pike's rules 1 and 2 restate Tony Hoare's famous maxim "Premature optimization is the root of all evil." Looks like wrongly attributed to Hoare? That famous quote is by Knuth http://wiki.c2.com/?PrematureOptimization https://en.wikiquote.org/wiki/Donald_Knuth

There's some debate about that. Knuth at one point (in Literate Programming) attributes it to Hoare, and Hoare later attributes it to Knuth.

[deleted]

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

#13

Post by candiodari »

It's just a cycle: procedural programming -> data oriented programming -> object oriented programming -> functional programming

procedural programming -> 'I hate all these imperative sequences ("flowcharts"), it's all about the data anyway !'

data oriented programming -> 'I hate keeping all these data relationships in sync, can't the data do that itself ?'

object oriented programming -> 'all this behavior is too complex, often does things I don't intend, can't it be simpler ?'

functional programming -> "it's simple, but way too dense (like algebra), can't we just write out what happens in sequences of imperative statements ?"

So we arrive at Wapper's "Battlestar" law of programming paradigms:

"All Of This Has Happened Before And All Of It Will Happen Again"

Object oriented programming is where really complex and large programs go. I agree with Pike : my favorite is data-oriented programming. Read the data and relationships, but only document them, don't encode the data schema directly. But here's the kicker:

The issue with these Pike 5 rules is that while some things are simple (and yes, people can screw up and make simple things complex), there are many things that are complex and can't be made simpler without destroying the functionality of the program. There is no way to make a CAD drawing program that is anything remotely close to these rules. Making such a program simple and predictable, while possible, also destroys its function.

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

#14

Post by mamcx »

drostie wrote: post #8

I think #5, which is probably going to be thought of as great wisdom for our age, is secretly an empty tautology. That is, my amateurish work in schemas and validating data structures and type systems has led me to think that there is a somewhat hard-to-see but extremely-important bijection between data structures and the control structures that consume them. (In many ways this is theoretically a non-issue as there a…

This is "obvious" for more experienced programmers, but vastly missed all the time.

And the "experience" will change per-environment! Think in how many apply something like this well enough when inside his programming language, yet fail when using a RDBMS/NOSQL/CACHE/KV store. Or moving between UI/Backend. Or using the network, etc.

ie. Is easy to see the truth at low-scale but do the same across all the stack is another thing.

----

I have some anecdote from my early days, when doing a school management app. After almost finished the porting from FoxPro DOS 2.6 (procedural) to Visual FoxPro 3 (OO, procedural, sql) some task were far slower than in DOS.

Eventually I "discover" that was because some tables were normalized "by rows" instead of "by columns" (ie: The central process was around a table that, when printed in paper, was very much alike a pivot table). Then I change the tables to be as 1-1 to that pivot table. This massively improve the WHOLE program. Not only speed, but the simplification in coding and reduction on lines of the program was very big!

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

#15

Post by mpweiher »

avinassh wrote: post #5

> Pike's rules 1 and 2 restate Tony Hoare's famous maxim "Premature optimization is the root of all evil." Looks like wrongly attributed to Hoare? That famous quote is by Knuth http://wiki.c2.com/?PrematureOptimization https://en.wikiquote.org/wiki/Donald_Knuth

Full Knuth quote:

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."

1. It is only ever about small efficiencies.

2. And about small efficiencies in the 97% non-critical parts

So:

1. It is always valid to concern yourself with large efficiencies.

2. In the critical 3%, it is also legitimate to worry about small efficiencies.

For context, later in the same paper (Structured Programming with goto statements):

“The conventional wisdom [..] calls for ignoring efficiency in the small; but I believe this is simply an overreaction [..] In established engineering disciplines a 12% improvement, easily obtained, is never considered marginal; and I believe the same viewpoint should prevail in software engineering."

So his actual message is pretty much the opposite of what is attributed to him.

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

#16

Post by [deleted] »

candiodari wrote: post #13

It's just a cycle: procedural programming -> data oriented programming -> object oriented programming -> functional programming procedural programming -> 'I hate all these imperative sequences ("flowcharts"), it's all about the data anyway !' data oriented programming -> 'I hate keeping all these data relationships in sync, can't the data do that itself ?' object oriented programming -> 'all this behavior is too comp…

[deleted]

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

#17

Post by johansch »

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

This should have been #1.

Really. In all of my 20 years of designing and writing software products, I have the learned that pretty much all of the work depends on the data model/the data structures.

(And also: once you have you have understood the data structures of a program, you kinda understand the program too.)

It is by far the number one mistake for juniors to do - focusing on the code rather than on the data structures.

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

#18

Post by eikenberry »

candiodari wrote: post #13

It's just a cycle: procedural programming -> data oriented programming -> object oriented programming -> functional programming procedural programming -> 'I hate all these imperative sequences ("flowcharts"), it's all about the data anyway !' data oriented programming -> 'I hate keeping all these data relationships in sync, can't the data do that itself ?' object oriented programming -> 'all this behavior is too comp…

>.. there are many things that are complex and can't be made simpler without destroying the functionality of the program.

This is because we haven't figured out how to make them simple yet. I believe all problems can be made simple, once we come up with the proper system. Maybe we don't have the correct abstractions yet or just haven't figured out the best data layout. We've only been collectively programming for a few years now I think we have plenty of room left to advance the field. I'm not ready to just throw in the towel and say impossible.

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

#19

Post by agumonkey »

candiodari wrote: post #13

It's just a cycle: procedural programming -> data oriented programming -> object oriented programming -> functional programming procedural programming -> 'I hate all these imperative sequences ("flowcharts"), it's all about the data anyway !' data oriented programming -> 'I hate keeping all these data relationships in sync, can't the data do that itself ?' object oriented programming -> 'all this behavior is too comp…

You forgot logic programming -> I don't care how, just walk all feasible paths

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

#20

Post by fiddlerwoaroof »

mpweiher wrote: post #15
avinassh wrote: post #5

> Pike's rules 1 and 2 restate Tony Hoare's famous maxim "Premature optimization is the root of all evil." Looks like wrongly attributed to Hoare? That famous quote is by Knuth http://wiki.c2.com/?PrematureOptimization https://en.wikiquote.org/wiki/Donald_Knuth

Full Knuth quote: "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%." 1. It is only ever about small efficiencies. 2. And about small efficiencies in the 97% non-critical parts So: 1. It is always valid to concern yourself with large efficiencies. 2. In the critical 3%, it is also legit…

The issue though is that optimizing for performance is, in most cases, optimizing for the wrong thing if it makes your code harder to understand, maintain and test.
Post reply on HN