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

51–60 of 122 posts

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

#51

Post by winterlight »

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…

Ironically, in that situation, using a list might end up being more efficient due to cache locality. Or not. That's why measuring is so important, since performance can be a very counterintuitive subject. Hard-data should always prevail over theory and guesswork.

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

#52

Post by eternalban »

threatofrain wrote: post #37

The sum of these rules seem to imply that it's difficult to theoretically model programming, so always wait for your program to be fully written so you can perform some brute force empiricism -- and only then think about performance.

It is not true that you can not "theoretically" (read: based on formal reasoning) model program performance. You don't need to run a program to determine that an O(n^2) approach will be slower than an O(log n) algorithm. You do not need to run a program to determine the impact of optimizing a bit of your para code; you can get fairly good sense using Amdahl's law. Etc.

Like his creation, the Go language, Rob Pike's rules are somewhat condescending and patronizing those he deems as lesser programmers.

Rule 3, however, is the exception. That is the take away gem based on experience.

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

#53

Post by rdiddly »

smegel wrote: post #36
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…

How is writing code that loops over a list simpler than calling: things.Get("key") ?

In terms of programmer time/effort, using .Get() is simpler.

In terms of program speed/optimization, the answer depends on how .Get() is implemented.

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

#54

Post by DamonHD »

seanmcdirmid wrote: post #50
Sniffnoy wrote: post #30

Earlier quoted context omitted.

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

One could easily implement a hash set with an array, the reverse is not true at all. From the outside, arrays are extremely flexible, powerful, and complex constructs; a set, even a hash set, is not. If it is easy to procure a set (as a hash set), then sets should be used when they could be used instead of arrays (unless there are performance concerns to using sets). In languages that do not include batteries (e.g. C…

I'm probably missing something, but eg awk implements its 'arrays' at least logically with something like a hash set, and indeed hash sets can be great for (say) sparse arrays.

Lots of low-level data structures can be implemented in terms of one another, and which makes sense depends on circumstance.

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

#55

Post by [deleted] »

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.

[deleted]

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

#56

Post by seanmcdirmid »

winterlight wrote: post #48
smegel wrote: post #36

Earlier quoted context omitted.

How is writing code that loops over a list simpler than calling: things.Get("key") ?

The interface is the same. For example, in C# you have an interface Collection, which offers a lookup method, and which both HashSet and Lists implement. The point of the OP is that among different implementations for the same interface, choose the simplest one unless you have empirical evidence that compels you to do otherwise.

Arrays didn't implement interfaces in C# until the Linq release. But the main problem is that arrays have an interface st is much more complex than just ICollection, they have functionality you don't want to be used and that should be properly encapsulated.

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

#58

Post by icebraining »

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…

"Object-oriented design is the roman numerals of computing." -- Rob Pike

(He also designed his latest language without inheritance)

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

#59

Post by evincarofautumn »

johansch wrote: post #45
amelius wrote: post #44

Earlier quoted context omitted.

I've found that even as a user it is very useful to have a mental image of what the "data model" looks like, abstractly. This is more important than knowing about all the features of an application. I'm thinking user documentation should start with a quick explanation of the data model, and from there describe the operations that can be performed on it.

Yeah, the data structures define the program. Both downwards towards the developer and upwards towards the user.

This reminds me of a quote about Blender, which I find has a remarkably solid architecture based on the idea of interactively editing a sort of “scene database”:

“Although some jokingly called Blender a ‘struct visualizer’, the name is actually quite accurate. During the first months of Blender's development, we did little but devise structures and write include files. During the years that followed, mostly tools and visualization methods were worked out.”

And the architecture of a compiler I’ve been working on has gotten considerably simpler and more solid as I’ve figured out the right data structures—with the right data model, especially if it’s enforced with types, the code practically writes itself. Finding that model is the hard part.

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

#60

Post by smegel »

winterlight wrote: post #48
smegel wrote: post #36

Earlier quoted context omitted.

How is writing code that loops over a list simpler than calling: things.Get("key") ?

The interface is the same. For example, in C# you have an interface Collection, which offers a lookup method, and which both HashSet and Lists implement. The point of the OP is that among different implementations for the same interface, choose the simplest one unless you have empirical evidence that compels you to do otherwise.

> which offers a lookup method, and which both HashSet and Lists implement

How does a List map values to key? How does it even represent them?

Post reply on HN