I used this with Claude to cross compare against my current project and it found 11 pretty significant improvements. Very awesome set of prompts for the ai to then work on.
Rob Pike’s Rules of Programming (1989)
421–430 of 483 posts
Re: Rob Pike’s Rules of Programming (1989)
#422Earlier quoted context omitted.
Sure but the default (and usually correct) assumption when working at google (as an example) is basically "all numbers are big", so you you have to cluey about algorithms and data structures and not default to brute forcing something. At 99% of shops it should be the other way around .
Even when you are working with large numbers, most numbers are usually small. Most of the code is probably not dealing with the large things, and a large thing may consist of a large number of instances that are individually small. I've personally found it useful to always have concrete numbers in mind. An algorithm or data structure designed for N will probably be fine for N/10 and 10N, but it will often be ineffici…
[deleted]
Re: Rob Pike’s Rules of Programming (1989)
#423Earlier quoted context omitted.
Yeah, but I doubt many of the newer generation are going to read this. I manage a team of engineers, and one of the recent-ish graduates asked me in our 1-on-1 if it's still worth learning Python given that he can just write prompts. (Python is the language all our tools use). If the next generation doesn't even want to learn a programming language, they're definitely not going to learn how to write _clean_ code. May…
Junior here. There are still a few of us who value books and documentation. It's a weird time though. Hard to feel confident that you're learning in the correct way. Anyway, I've found that if you want to get a coworker into reading technical books, the best way is with a novel or three. I've had good success with The Martian. The Phoenix Project might work too. Slip them fun books until they've built a habit and the…
> Hard to feel confident that you're learning in the correct way.
This was hard before, too.
Re: Rob Pike’s Rules of Programming (1989)
#424Take a look at the page title. I guess he didn't follow his own rules for this 100-line HTML file Rob Pike's 5 Rules of Programming
The page was created by some CS professor at UNC, not by Pike.
Pike's rules are from 1989, which is before it was common to publish HTML.
Re: Rob Pike’s Rules of Programming (1989)
#425In a world of AI coding I think rule 5 is still as important than ever. I don’t validate everything Claude does but I do put attention on data structure design since it’s so important.
Re: Rob Pike’s Rules of Programming (1989)
#426I think it's fine and generous that he credited these rules to the better-known aphorisms that inspired them, but I think his versions are better, they deserve to be presented by themselves, instead of alongside the mental clickbait of the classic aphorisms. They preserve important context that was lost when the better-known versions were ripped out of their original texts. For example, I've often heard "premature op…
[dead]
Re: Rob Pike’s Rules of Programming (1989)
#427The attribution to Hoare is a common error — "Premature optimization is the root of all evil" first appeared in Knuth's 1974 paper "Structured Programming with go to Statements." Knuth later attributed it to Hoare, but Hoare said he had no recollection of it and suggested it might have been Dijkstra. Rule 5 aged the best. "Data dominates" is the lesson every senior engineer eventually learns the hard way.
If Dijkstra blamed Knuth it would have been the best recursive joke ever.
[dead]
Re: Rob Pike’s Rules of Programming (1989)
#428[flagged]
Premature abstraction is one of the worst pitfalls when writing software. It's paid for up front, it costs developer time to understand and work with, it adds complexity (tech debt), increases likeliness of bugs, and increases refactor time. All for someone to say "if we ever want to do X". If we wanted to do it, we'd do it now. I truly believe this comes from devs who want to feel smart by "architecting" solutions t…
I think it mostly happens because a little bit of abstraction is nearly always uncontroversially good. If you want to print a line of text 5 times, you'll instinctively write a for loop to do it, instead of copy-pasting the original print() statement an extra 4 times. The cognitive overhead upon reading this code is near zero, since we're all so familiar with it. This is abstraction, nonetheless.
So a little bit is always good, and more is sometimes very good -- even memorably good. Together these cause many of us to extrapolate too far, but for understandable reasons.
Re: Rob Pike’s Rules of Programming (1989)
#429Earlier quoted context omitted.
I still firmly believe that one ctx object and hundred functions/methods is as bad as programming with plain variables defined in the global scope. If the ctx is composed from smaller data structures with whom the functions are defined, then all is good. This is the opposite of the rule.
But why? You keep saying you believe it, but that is literally what a database is, game state manipulation, string manipulation, iterator algorithms, list comprehensions, range algorithms, image manipulations, etc. These are all instances where you use the same data structures over and over with as many algorithms and functions and you need.
It’s about coupling and being able to maintain that in the long term. A narrow focus helps to test each individual unit in isolation from each other. It is true that a database appears to be a single datastructure with hundreds of methods from the users perspective and that is fine, because someone else engineered and tested it for you. However if you were to look into how a database is implemented you would get to see the composition of data structures, like btrees that are tested in isolation.
Re: Rob Pike’s Rules of Programming (1989)
#430Rob Pike is programming God of retardmaxxing. Go programming language is a good example of this, where it was the dumbest language for a longgg time.