I really like rule 5. It's can be extremely hard to get data structures right, but you really notice when you do. I had the chance to redo a project, and the biggest chances was to how data was structured and it made a world of difference.
I have found this to be true as well. The first thing I do whenever reviewing an open source project is to examine the database schema. I can usually figure out what the code does and how it works by looking at the tables and the relationships between them.
Linus agrees: „…git actually has a simple design, with stable and reasonably well-documented data structures. 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.“
These are all well and good, as long as you remember not to blindly live by them (which you'll often see people do with advice from authority).
> 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.
I'm not sure what the author wants me to take away from this? Data structures and algorithms should very much both be taken into consideration, although I'd agree that "it all starts with the choice data structure".
All too often we focus on performance as the main problem we're trying to solve, when, in reality, our chief problem is managing complexity.
A clever algorithm can often dramatically improve performance, but usually clever algorithms are difficult to understand and their unmaintainability leads them to be abandoned as a project evolves, or, worse, subtly break when assumptions no longer hold. (Its especially hard when working with other developers)
The only example that was coming immediately to mind was a distributed lock. Once you have that primitive available your distributed systems problem can be substantially simpler to implement. Without it writing race-free code is going to be really tricky.
On one hand I love these and consider them good advice. On the ther they’re often used as a weak crutch for poor programming practices, usually by developers who believe any amount of money spent on infrastructure is worth it to avoid the catastrophic consequences of maybe thinking about performance in their code. They’re certain they never want to optimize too early, and they’re certain that every day is too early.
I can't even remember all the times this has hit me. Often times, I'll be working on a module, and the code will just be ugly, hard to understand, hard to write. Then, I'll make a small change to the organization of the data structures I'm working on (normally, literally a change in the set of data that is a field of one struct or another, or a parameter to one function or another) and suddenly everything will become clear. These days, if code is getting ugly, the first thing I try to do is look at whether the relevant data is logically grouped, because nine times out of ten, this ends up being the problem. I only wish I was better at getting it right the first time.
> Pike's rules 1 and 2 restate Tony Hoare's famous maxim "Premature optimization is the root of all evil."
That quote is from Knuth, not Hoare.
https://shreevatsa.wordpress.com/2008/05/16/premature-optimi...
The Hoare attribution is also (at least in part) due to Knuth so it all comes out about even in the end.
Link change?
http://users.ece.utexas.edu/~adnan/pike.html
Yes. Changed from http://blog.codonomics.com/2017/09/rob-pikes-5-rules-of-prog....
It's also a dupe: https://hn.algolia.com/?query=pike%20rules&sort=byDate&dateR...
Content is shamelessly copy-pasted from http://users.ece.utexas.edu/~adnan/pike.html*
I really like rule 5. It's can be extremely hard to get data structures right, but you really notice when you do. I had the chance to redo a project, and the biggest chances was to how data was structured and it made a world of difference.
I have found this to be true as well. The first thing I do whenever reviewing an open source project is to examine the database schema. I can usually figure out what the code does and how it works by looking at the tables and the relationships between them.
Linus agrees: „…git actually has a simple design, with stable and reasonably well-documented data structures. 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.“
These are all well and good, as long as you remember not to blindly live by them (which you'll often see people do with advice from authority).
> 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.
I'm not sure what the author wants me to take away from this? Data structures and algorithms should very much both be taken into consideration, although I'd agree that "it all starts with the choice data structure".
All too often we focus on performance as the main problem we're trying to solve, when, in reality, our chief problem is managing complexity.
A clever algorithm can often dramatically improve performance, but usually clever algorithms are difficult to understand and their unmaintainability leads them to be abandoned as a project evolves, or, worse, subtly break when assumptions no longer hold. (Its especially hard when working with other developers)
The only example that was coming immediately to mind was a distributed lock. Once you have that primitive available your distributed systems problem can be substantially simpler to implement. Without it writing race-free code is going to be really tricky.
I've witnessed the unfortunate consequences when each of these rules were violated.
I've seen kludgy code when Rules 1 and 2 are violated for instance.
Employing Fancy algorithms to look good among peers, leaving behind buggy and maintainable code.
Rule 5 violation is deceptive. Often one can get it right with right understanding of business use-case.
The worst part is not the violation of these rules but the developer's chest-thumping with pride for writing seemingly intelligent code :-/
On one hand I love these and consider them good advice. On the ther they’re often used as a weak crutch for poor programming practices, usually by developers who believe any amount of money spent on infrastructure is worth it to avoid the catastrophic consequences of maybe thinking about performance in their code. They’re certain they never want to optimize too early, and they’re certain that every day is too early.
Understanding and living by Rule 5 is, in my book, what separates good and great programmers.
I can't even remember all the times this has hit me. Often times, I'll be working on a module, and the code will just be ugly, hard to understand, hard to write. Then, I'll make a small change to the organization of the data structures I'm working on (normally, literally a change in the set of data that is a field of one struct or another, or a parameter to one function or another) and suddenly everything will become clear. These days, if code is getting ugly, the first thing I try to do is look at whether the relevant data is logically grouped, because nine times out of ten, this ends up being the problem. I only wish I was better at getting it right the first time.
Rod Burstall of Edinburgh University said pithily: "Efficiency is the enemy of clarity"
"Premature optimization is the root of all evil."
Except in an interview ;)
Sound principles, as usual.
That is pretty nice topic.