There are actually six rules!
Rob Pike’s Rules of Programming (1989)
141–150 of 332 posts
Re: Rob Pike’s Rules of Programming (1989)
#142A quote from one of our founders that I've always liked: If you make an optimization that was not at a bottleneck, you did not make an optimization.
You made an optimization for the future when enough bottlenecks have been fixed such that this one part becomes the bottleneck.
There are several assumptions that are far from a given with premature optimization.
1. Adding the optimization didn’t make the code more complicated.
2. Adding the optimization didn’t introduce a bug.
3. This part of the code will be a bottleneck in the future. The time spent optimizing is a write-off if the project is canceled or that portion is replaced.
Re: Rob Pike’s Rules of Programming (1989)
#143Am 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.
If it's fairly easy, then I think it still fits the spirit of the rules. KISS and all. On the other hand, the idea that one might be setting traps is slightly weird... if you _know_ 90% that n will be large then pick an algorithm that's efficient (and since it's easy to implement, it's a win-win). If n is always going to be small, then does the choice really matter?
If N is known small you should favor simplicity and readability over complex optimization.
Re: Rob Pike’s Rules of Programming (1989)
#144Modeling the problem domain is so important that I dont know why the first year of every compsci undergrad program isnt entirely dedicated to teaching the idea.
Instead, day 1 is installing python or java, running hello world and talking about pointers, binary, encoding, logic gates, etc.
We should be teaching students on day 1 that code is a liability and to be avoided whenever it is convenient to do so.
Re: Rob Pike’s Rules of Programming (1989)
#145In 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
> Show me your tables, and I won't usually need your flowchart
A couple of years ago I spent quite some time trying to evaluate the tech stack (and general engineering culture) of merger/acquisition targets of my employer. It was quite a fun exercise, all said and done. I encountered all sorts; from a small team start up who had their tech sorted out more or less to a largish organisation who relied on IBM's ESB which exactly one person in their team knew how it worked!!
I discovered this exact method during the third tech evaluation exercise. When the team began explaining various modules top-down and user-flows etc., I politely interrupted them and asked for DB schema. It was just on a whim because I was bored of typical one way session interrupted by me asking minor questions. Once I had a hang of their schema rest of the session was literally me telling them what their control and user flows were and them validating it.
Since then it's become my magic wand to understand a new company or team. Just go directly to the schema and work backwards.
Conversely, I've begun paying more attention to data modelling. Because once a data model is fixed it's very hard to change and once enough data accumulates the inertia just increases and instead if changing the data model (for the fear of data migration etc.,) the tendency is to beat the use cases to fit the data model. It's not your usual fail-fast-and-iterate thing.
Re: Rob Pike’s Rules of Programming (1989)
#146In 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
That’s Dick Gabriel’s site; he posted gls’s essay there with attribution (so you didn’t realize which site it is). He and quux are friends and collaborators.
Re: Rob Pike’s Rules of Programming (1989)
#147In 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
as someone in ML, I see myself wanting the opposite. ML researchers drown their algorithms in huge tables of results, effectively spending time on "how well" rather than the "what". It often leads to things being added as long as they are better, with the conclusion of it being a gargantuan monster of models and hand-engineered changes. All with no one understanding how the whole things works as a single unit. Flow c…
"Flowchart" has historically, in Brook's time, meant "flow-of-control chart", and these usually degenerate into vast webs of minutia -- useless as abstractions.
But perhaps you meant "flow-of-data between structures" -- in which case we have agreement on engineering, but a muddle on semantics.
Re: Rob Pike’s Rules of Programming (1989)
#148Earlier quoted context omitted.
> Bad programmers worry about the code And yet, I see a whole swath of the industry hyper-focused on various linters/styling/rules.
> And yet, I see a whole swath of the industry hyper-focused on various linters/styling/rules. It seems to me that what you're actually seeing is an entire industry trying to eliminate all code-related issues, specially bike-shedding ones. This is patently obvious to anyone who was forced to waste their time in code review iterations discussing, say, where a brace should go and how many spaces someone should have add…
This usually a good time to apply the When In Rome rule. Do not reformat needlessly, follow the code style of the code you're modifying. Done.
(If multiple people are arguing back and forth in code review -- when following the WIR rule -- tell them about the WIR rule and that should settle it. If not, you have bigger problems in your team.)
Re: Rob Pike’s Rules of Programming (1989)
#149All this advice against "premature optimization" has created generations of programmers that don't understand how to use hardware efficiently. Here's the problem: If you profile software that is 100x slower than it needs to be on every level, there are no obvious bottlenecks . Your whole program is just slow across the board, because you used tons of allocations, abstractions and indirections at every step of the way…
> Rob Pike probably has never written a program where performance really mattered
Rob Pike has written window system software which ran in what now would be called a "thin client" over a 9600 baud modem and rendered graphics using a 2MHz CPU. He probably knows a thing or two about performance tuning.
Re: Rob Pike’s Rules of Programming (1989)
#150Earlier quoted context omitted.
Nobody was ever "forced to waste their time" on this stuff. I have a simple rule - I don't comment on other people's style, and if people comment on my style, I just go with their suggestions. Problem solved.
You've never been on a team with two people with opposing opinions I guess.
Just out of morbid curiosity... have you actually experienced multiple 'seniors' giving conflicting code review comments about code style (of all things)?
That sounds quite dysfunctional.
(EDIT: Sure, nitpicks may differ, but...)