Rob Pike’s Rules of Programming (1989)
users.ece.utexas.edu
Rob Pike’s Rules of Programming (1989)
1–10 of 332 posts
Re: Rob Pike’s Rules of Programming (1989)
#2"Write stupid code that uses smart objects"
That's a good one. It's amazing how much complexity can be created by using the wrong abstractions.
Re: Rob Pike’s Rules of Programming (1989)
#3[deleted]
Re: Rob Pike’s Rules of Programming (1989)
#4"Write stupid code that uses smart objects" That's a good one. It's amazing how much complexity can be created by using the wrong abstractions.
I frequently find that, when refactoring especially, you find a lot of big ol' god objects that are incomprehensible. But when you break them down into 5-10 small objects, suddenly the operation they were trying to do makes perfect sense.
Re: Rob Pike’s Rules of Programming (1989)
#5In The Mythical Man Month Fred Brooks said "Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious."
I first read that on Guy Steele's site: http://www.dreamsongs.com/ObjectsHaveNotFailedNarr.html
Re: Rob Pike’s Rules of Programming (1989)
#6Everyone building no code tools is learning or will learn that the problem most businesses have is not a lack of coding skill, or the inability to build the algorithm, but rather how to structure and model data in a sensible way in the first place.
Re: Rob Pike’s Rules of Programming (1989)
#7Am I wrong to avoid writing O(n^2) code if at all possible when it is fairly easy to use hash tables for a better time complexity? Sure when n is small the O(n^2) one will be faster but when n is small /anything/ you do is fast in absolute terms so I'm trying to not leave traps in my code just waiting for n to get bigger than initially expected.
Re: Rob Pike’s Rules of Programming (1989)
#8It turns out rule 5 (Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident) is both true but also hard.
Eric Evans' Domain Driven Design is a good book on the topic.
Re: Rob Pike’s Rules of Programming (1989)
#9Rule 5 seems to mirror one of my favorite insights from Alexander Stepanov:
> In 1976, still back in the USSR, I got a very serious case of food poisoning from eating raw fish. While in the hospital, in the state of delirium, I suddenly realized that the ability to add numbers in parallel depends on the fact that addition is associative. (So, putting it simply, STL is the result of a bacterial infection.) In other words, I realized that a parallel reduction algorithm is associated with a semigroup structure type. That is the fundamental point: algorithms are defined on algebraic structures.
This is also exemplified in the analytics infrastructure used at stripe: https://www.infoq.com/presentations/abstract-algebra-analyti...
Re: Rob Pike’s Rules of Programming (1989)
#10Am I wrong to avoid writing O(n^2) code if at all possible when it is fairly easy to use hash tables for a better time complexity? Sure when n is small the O(n^2) one will be faster but when n is small /anything/ you do is fast in absolute terms so I'm trying to not leave traps in my code just waiting for n to get bigger than initially expected.
[deleted]