Rule 5 is actually the same as Linus Torvalds said:
"Bad programmers worry about the code. Good programmers worry about data structures and their relationships."
Rob Pike’s Rules of Programming (1989)
41–50 of 122 posts
Re: Rob Pike’s Rules of Programming (1989)
#42Rule 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") ?
Your "Get" method hides complexity. It could be that it loops over a list, or that it hashes to find the bin, then loops over the list of items in the bin, or any of other dozens of other possible implementations.
So the next question is "What's the implementation of the Get(key) method?" Or maybe "Why aren't you using your language's library methods to loop over that list?"
Re: Rob Pike’s Rules of Programming (1989)
#43> 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 key is the phrase "easily obtained." Always balance the efficiency benefits against the programming costs, i.e. time & effort.
Re: Rob Pike’s Rules of Programming (1989)
#44"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 prog…
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.
Re: Rob Pike’s Rules of Programming (1989)
#45"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 prog…
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.
Re: Rob Pike’s Rules of Programming (1989)
#46Rule 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…
Rule 6 is a corollary of "Every principle, and every group or movement based on a principle, eventually becomes its own opposite."
Re: Rob Pike’s Rules of Programming (1989)
#47"Rule 1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is." Everything about reading this quote depends on what you think a "speed hack" is. Without practical agreement on that, you'll get a lot of people arguing past each other.
I'd say "a modification to the code designed to speed up that section of code". Are there other reasonable definitions? I thought it was pretty clear that the rule could be accurately paraphrased as "Don't optimize a section for speed until you're sure that's where it's needed."
Re: Rob Pike’s Rules of Programming (1989)
#48Rule 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") ?
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.
Re: Rob Pike’s Rules of Programming (1989)
#49Re: Rob Pike’s Rules of Programming (1989)
#50Earlier quoted context omitted.
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.
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), it makes sense to use an array simply because procuring a set isn't easy.