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

21–30 of 122 posts

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

#21

Post by spaceseaman »

eikenberry wrote: post #18
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 f…

Agreed. Our field is still incredibly young, speaking as if we've tried everything that can be tried sounds a lot like when physicists were figuring out relativity. Many believed that the problems were simply unsolvable, that all of physics had been figured out in the late 1800s. Obviously they were wrong, and I think many of today's computer scientists will be wrong as well. Our field has a long way to go before it matures, in the meantime we need to find better abstractions.

Claiming that it's "all a cycle" is incredibly short sighted considering the time-scale.

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

#22

Post by BatFastard »

saagarjha wrote: post #3

> If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Therin lies the rub: it’s hard to choose data structures.

Its easy to choose data structures, its hard to choose a good flexible data structure.

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

#23

Post by fergazen »

fergazen wrote: post #6

These are not "Rules of Programming", but are excellent "Guidelines for Performance". Having 30yrs under my belt I have come to all the same conclusions as Rob Pike over my years, so these are very deserving of some serious contemplation for those with In my current job we have lots of large and often 'sparsely populated' objects which means basically you can never count on any of the properties you were hoping would…

Oh I forgot. Asshat hackernews admins banned this account because I got into a disagreement withsomeone. What a bunch of snowflakes. use VPN account from now on and incognito mode, to distrupt their censorship capability.

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

#24

Post by pjc50 »

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 is no way to make a CAD drawing program that is anything remotely close to these rules.

Eh? A CAD program will have a lot of features, but that's not the same as using complex algorithms. For the bits where you do use complex algorithms, with a good architecture you can confine the complexity to plugins and corners of the program.

All of the other rules would apply to almost anything, surely?

Maybe the best example of irreducible complexity would be a video player; the algorithm is handed to you in a multi-hundred-page spec and there's nothing you can do to avoid that.

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

#25

Post by gue5t »

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…

How is a for-loop not a fold?

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

#26

Post by jaggederest »

saagarjha wrote: post #3

> If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Therin lies the rub: it’s hard to choose data structures.

I think the harder part, in my experience, is not just choosing data structures, but choosing ones that will remain relatively flexible through the life of the project, and changing them when they become problematic.

This is also a difficult investment to justify because, as always, it doesn't deliver any "user facing features". That makes me chuckle because most of the time the "feature" is that it continues to be possible to use the application at all.

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

#27

Post by whack »

Rule 6: Every well-intentioned rule will be bastardized and used to justify horrible code.

Foo: "Hey, this 10000-element collection, which we do repeated lookups on... why are we using a list and not a HashSet?"

Bar: "Because lists are so much simpler than a HashSet. Let's just KISS"

Foo: "But... doing repeated lookups on a 10k sized list is so much slower than just using a HashSet!"

Bar: "Oh really? Have you profiled the entire application, and measured the latency impact caused by this decision? Come back to me once you've done so, and until then, we're not going to tune for speed."

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

#28

Post by seanmcdirmid »

whack wrote: post #27

Rule 6: Every well-intentioned rule will be bastardized and used to justify horrible code. Foo: "Hey, this 10000-element collection, which we do repeated lookups on... why are we using a list and not a HashSet?" Bar: "Because lists are so much simpler than a HashSet. Let's just KISS" Foo: "But... doing repeated lookups on a 10k sized list is so much slower than just using a HashSet!" Bar: "Oh really? Have you profile…

If they don't need order, a hash set is indeed more simple conceptually.

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

#29

Post by vram22 »

agumonkey wrote: post #19
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

Heh, good one. But maybe slightly changed to:

I don't care how well (as in perf)

unless you meant something else (not skilled at logic programming).

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

#30

Post by Sniffnoy »

seanmcdirmid wrote: post #28
whack wrote: post #27

Rule 6: Every well-intentioned rule will be bastardized and used to justify horrible code. Foo: "Hey, this 10000-element collection, which we do repeated lookups on... why are we using a list and not a HashSet?" Bar: "Because lists are so much simpler than a HashSet. Let's just KISS" Foo: "But... doing repeated lookups on a 10k sized list is so much slower than just using a HashSet!" Bar: "Oh really? Have you profile…

If they don't need order, a hash set is indeed more simple conceptually.

A set, the abstract interface, is simpler conceptually than a list. A hash set, the particular implementation of a set, is more complex.
Post reply on HN