Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rob Pike’s Rules of Programming (1989)

cs.unc.edu

Post reply on HN
Print view View original

111–120 of 483 posts

Re: Rob Pike’s Rules of Programming (1989)

#111

Post by kalaksi »

devnullbrain wrote: post #101
anymouse123456 wrote: post #93

There are very few phrases in all of history that have done more damage to the project of software development than: "Premature optimization is the root of all evil." First, let's not besmirch the good name of Tony Hoare. The quote is from Donald Knuth, and the missing context is essential. From his 1974 paper, "Structured Programming with go to Statements": "Programmers waste enormous amounts of time thinking about,…

> and the missing context is essential. Oh yes, I'd recommend everyone who uses the phrase reads the rest of the paper to see the kinds of optimisations that Knuth considers justified. For example, optimising memory accesses in quicksort.

This shows how hard it is to create a generalized and simple rule regarding programming. Context is everything and a lot is relative and subjective.

Tips like "don't try to write smart code" are often repeated but useless (not to mention that "smart" here means over-engineered or overly complex, not smart).

Re: Rob Pike’s Rules of Programming (1989)

#112

Post by embedding-shape »

anymouse123456 wrote: post #110
aljgz wrote: post #108

Earlier quoted context omitted.

In all honesty, this is one of the less abused quotes, and I have seen more benefit from it than harm. Like you, I've seen people produce a lot of slow code, but it's mostly been from people who would have a really hard time writing faster code that's less wrong. I hate slow software, but I'd pick it anytime over bogus software. Also, generally, it's easier to fix performance problems than incorrect behavior, especia…

I don't believe there is any tension at all between fast and simple software. We can and should have both. This is a fraud, made up by midwits to justify their leaning towers of abstraction.

User-facing, sure, nothing stopping us from doing "simple and fast" software. But when it comes to the code, design and architecture, "simple" is often at odds with "fast", and also "secure". Once you need something to be fast and secure, it often leads to a less simple design, because now you care about more things, it's kind of hard to avoid.

Re: Rob Pike’s Rules of Programming (1989)

#113

Post by mikepurvis »

ignoramous wrote: post #96
mikepurvis wrote: post #86

Earlier quoted context omitted.

I think this is sometimes a barrier to getting started for me. I know that I need to explore the data structure design in the context of the code that will interact with it and some of that code will be thrown out as the data structure becomes more clear, but still it can be hard to get off the ground when me gut instinct is that the data design isn't right. This kind of exploration can be a really positive use case…

> This kind of exploration can be a really positive use case for AI I think Not sure if SoTA codegen models are capable of navigating design space and coming up with optimal solutions. Like for cybersecurity, may be specialized models (like DeepMind's Sec-Gemini ), if there are any, might? I reckon, a programmer who already has learnt about / explored the design space, will be able to prompt more pointedly and evalua…

Yeah key word is exploration. It's not "hey Claude write the design doc for me" but rather, here's two possible directions for how to structure my solution, help me sketch each out a bit further so that I can get a better sense what roadblocks I may hit 50-100 hours into implementation when the cost of changing course is far greater.

Re: Rob Pike’s Rules of Programming (1989)

#114

Post by Rygian »

tangus wrote: post #87
embedding-shape wrote: post #2

"Epigrams in Programming" by Alan J. Perlis has a lot more, if you like short snippets of wisdom :) https://www.cs.yale.edu/homes/perlis-alan/quotes.html > Rule 5. Data dominates. 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. Always preferred Perlis' version, that might be slightly o…

Aren't they basically saying opposite things? Perlis is saying "don't choose the right data structure, shoehorn your data into the most popular one". This advice might have made sense before generic programming was widespread; I think it's obsolete.

Pike: strongly typed logic is great!

Perlin: stringly typed logic is great!

Re: Rob Pike’s Rules of Programming (1989)

#115

Post by bko »

anymouse123456 wrote: post #93

There are very few phrases in all of history that have done more damage to the project of software development than: "Premature optimization is the root of all evil." First, let's not besmirch the good name of Tony Hoare. The quote is from Donald Knuth, and the missing context is essential. From his 1974 paper, "Structured Programming with go to Statements": "Programmers waste enormous amounts of time thinking about,…

> Multiple generations of programmers have now been raised to believe that brutally inefficient, bloated, and slow software is just fine. There is no limit to the amount of boilerplate and indirection a computer can be forced to execute. There is no ceiling to the crystalline abstractions emerging from these geniuses. There is no amount of time too long for a JVM to spend starting.

I think that's due to people doing premature optimization! If people took the quote to heart, they would be less inclined to increasing the amount of boilerplate and indirection.

Re: Rob Pike’s Rules of Programming (1989)

#116

Post by YesThatTom2 »

anymouse123456 wrote: post #93

There are very few phrases in all of history that have done more damage to the project of software development than: "Premature optimization is the root of all evil." First, let's not besmirch the good name of Tony Hoare. The quote is from Donald Knuth, and the missing context is essential. From his 1974 paper, "Structured Programming with go to Statements": "Programmers waste enormous amounts of time thinking about,…

I hear you, friend!

While you were seeing those problems with Java at Google, I saw seeing it with Python.

So many levels of indirection. Holy cow! So many unneeded superclasses and mixins! You can’t reason about code if the indirection is deeper than the human mind can grasp.

There was also a belief that list comprehensions were magically better somehow and would expand to 10-line monstrosities of unreadable code when a nested for loop would have been more readable and just as fast but because list comprehensions were fetishized nobody would stop at their natural readability limits. The result was like reading the run-on sentence you just suffered through.

Re: Rob Pike’s Rules of Programming (1989)

#117

Post by twoodfin »

anymouse123456 wrote: post #93

There are very few phrases in all of history that have done more damage to the project of software development than: "Premature optimization is the root of all evil." First, let's not besmirch the good name of Tony Hoare. The quote is from Donald Knuth, and the missing context is essential. From his 1974 paper, "Structured Programming with go to Statements": "Programmers waste enormous amounts of time thinking about,…

Ignoring optimization opportunities until you see the profile only works when you actually profile!

Profiling never achieved its place in most developers’ core loop the way that compiling, linting, or unit testing did.

How many real CI/CD pipelines spit out flame graphs alongside test results?

Re: Rob Pike’s Rules of Programming (1989)

#118

Post by gspr »

aljgz wrote: post #108
anymouse123456 wrote: post #93

There are very few phrases in all of history that have done more damage to the project of software development than: "Premature optimization is the root of all evil." First, let's not besmirch the good name of Tony Hoare. The quote is from Donald Knuth, and the missing context is essential. From his 1974 paper, "Structured Programming with go to Statements": "Programmers waste enormous amounts of time thinking about,…

In all honesty, this is one of the less abused quotes, and I have seen more benefit from it than harm. Like you, I've seen people produce a lot of slow code, but it's mostly been from people who would have a really hard time writing faster code that's less wrong. I hate slow software, but I'd pick it anytime over bogus software. Also, generally, it's easier to fix performance problems than incorrect behavior, especia…

> I have seen more benefit from it than harm.

Same. I, too, am sick of bloated code. But I use the quote as a reminder to myself: "look, the fact that you could spend the rest of the workday making this function run in linear instead of quadratic time doesn't mean you should – you have so many other tasks to tackle that it's better that you leave the suboptimal-but-obviously-correct implementation of this one little piece as-is for now, and return to it later if you need to".

Re: Rob Pike’s Rules of Programming (1989)

#120

Post by sph »

anymouse123456 wrote: post #93

There are very few phrases in all of history that have done more damage to the project of software development than: "Premature optimization is the root of all evil." First, let's not besmirch the good name of Tony Hoare. The quote is from Donald Knuth, and the missing context is essential. From his 1974 paper, "Structured Programming with go to Statements": "Programmers waste enormous amounts of time thinking about,…

Another one from my personal experience: apply DRY principles (don't repeat yourself) the third time you need something. Or in other words: you're allowed to copy-and-paste the same piece of code in two different places.

Far too often we generalise a piece of logic that we need in one or two places, making things more complicated for ourselves whenever they inevitably start to differ. And chances are very slim we will actually need it more than twice.

Premature generalisation is the most common mistake that separates a junior developer from an experienced one.

Post reply on HN