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

241–250 of 483 posts

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

#241

Post by pydry »

devnullbrain wrote: post #203
pydry wrote: post #173

Earlier quoted context omitted.

I dunno, Ive seen people try to violate "dont prematurely optimize" probably a thousand times (no exaggeration) and never ONCE seen this happen: 1. Somebody verifies with the users that speed is actually one of the most burning problems. 2. They profile the code and discover a bottleneck. 3. Somebody says "no, but we shouldnt fix that, that's premature optimization!" Ive heard all sorts of people like OP moan that "t…

>1. Somebody verifies with the users that speed is actually one of the most burning problems. Sometimes this is too late. C++98 introduce `std::set` and `std::map`. The public interface means that they are effectively constrained to being red-black trees, with poor cache locality and suboptimal lookup. It took until C++11 for `std::unordered_map` and `std::unordered_set`, which brought with them the adage that you sh…

You've inadvertently made an argument for deprecation, not ignoring rob's rule.

When building interfaces you are bound to make mistakes which end users will end up depending on (not just regarding optimization).

The correct lesson to learn from this is not "just dont make mistakes" but to try and minimize migration costs to prevent these mistakes from getting tightly locked in and try to detect these mistakes earlier on in the design process with more coordinated experimentation.

C++ seems pretty bad at both. It's not unusual, either - migration and upgrade paths are often the most neglected part of a product.

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

#242

Post by 01100011 »

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,…

This is the sort of pontifical statement that old guys like me tend to make which is strictly wrong but also contains a lot of wisdom.

Yes, software is bloated, full of useless abstractions and bad design. You kids(well, anyone programming post 1980, so myself included) should be ashamed. Also let's not forget that those abstractions helped us solve problems and our friends in silicon valley(ok that no longer makes sense but imagine if SillyValley still just made HW) covered our mistakes. But yeah, we write crap a lot of the time.

But as other folks have said, it doesn't mean "don't optimize."

I've always used my own version of the phrase, which is: "Don't be stupid." As in, don't do dumb, expensive things unless you need to for a prototype. Don't start with a design that is far from optimal and slow. After profiling, fix the slow things. I'm pretty sure that's what most folks do on some level.

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

#243

Post by redbar0n »

lokar wrote: post #195
Megranium wrote: post #185

Earlier quoted context omitted.

Huh, I've always understood that quote very differently, with emphasis on "premature" ... not as in, "don't optimize" but more as in "don't optimize before you've understood the problem" ... or, as a CS professor of mine said "Make it work first, THEN make it work fast" ...

And if you know in advance that a function will be in the critical path, and it needs to perform some operation on N items, and N will be large, it’s not premature to consider the speed of that loop.

Just remember Rob Pike's 1st rule: don't assume where bottlenecks will occur, but verify it.

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

#245

Post by colechristensen »

chuckadams wrote: post #236
colechristensen wrote: post #225

Earlier quoted context omitted.

Making maintainable code is a good goal. DRY is one step removed from that goal and people use it to make very unmaintainable code because they confuse any repeated code with unmaintainability. (or their theory that some day we might want to repeat this code so we might as well pre-DRY it) The result is often a horrendous complex mess. Imagine a cookbook with a cookie recipe that resided on 47 different pages (40 of…

It's almost like there's a "reasonable person" type of standard that's impossible to nail down in a general rule...

If you can describe a rule in one sentence it'll probably lead to as much trouble as it fixes.

The problem is zealots. Zealotry doesn't work for indeterminate things that require judgement like "code quality" or "maintainability", but a simple rule like "don't repeat yourself" is easy for a zeal. They take a rule and shut down any argument with "because the rule!"

If you're arguing about code quality and maintainability without one sentence rules then you actually have to make arguments. If the rule is your argument there's no discussion only dogma.

As a result? Easy to distill rules spread fast, breed zealots, and result in bad code.

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

#246

Post by eyelidlessness »

tikhonj wrote: post #166
sph wrote: post #120

Earlier quoted context omitted.

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 wil…

The rule of 3 is awful because it focuses on the wrong thing. If two instances of the same logic represent the same concept, they should be shared. If 10 instances of the same logic represent unrelated concepts, they should be duplicated. The goal is to have code that corresponds to a coherent conceptual model for whatever you are doing, and the resulting codebase should clearly reflect the design of the system. Once…

I agree. And I think this also distills down to Rob Pike’s rule 5, or something quite like it. If your design prioritizes modeling the domain’s data, shaping algorithms around that model, it’s usually trivial to determine how likely some “duplication” is operating on shared concepts, versus merely following a similar pattern. It may even help you refine the data model itself when confronted with the question.

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

#247

Post by mort96 »

sph wrote: post #120
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 wil…

IMO, the right way to think about DRY is to consider why a given piece of code would ever change.

If you have two copies of some piece of code, and you can reasonably say that if you ever want to update one copy then you will almost certainly want to update the other copy as well, then it's probably a good idea to try to merge them and keep that logic in some centralized place.

On the other hand, if you have three copies of the same piece of code, but they kind of just "happen to" be identical and it's completely plausible that any one of the copies will be modified in the future for reasons which won't affect the other copies, maybe keeping them separate is a good idea.

And of course, it's sometimes worth it to keep two or more different copies which do share the same "reason to change". This is especially clear when you have the copies in different repositories, where making the code "DRY" would mean introducing dependencies between repositories which has its own costs.

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

#248

Post by whatever1 »

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,…

At least before the LLM world you would have to trade money (aka more compute) for time to market. What is the point of spending a single second optimizing a query when your database has 10 users?

Of course today this has changed. You can have multiple agents working on micro optimizing everything and have the pie and eat it too.

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

#249

Post by MyHonestOpinon »

embedding-shape wrote: post #112
anymouse123456 wrote: post #110

Earlier quoted context omitted.

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.

> "simple" is often at odds with "fast"

Sort of. But if you keep the software simple, then it is easier to optimize the bottlenecks. You don't really need to make everything complicated to make it faster, just a few well selected places need to be refactored.

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

#250

Post by pphysch »

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,…

It has less to do with a quote and more to do with CS education (and the market) rewarding minimal functionality over performance, security, fault-tolerance, etc.

The average university CS student in USA (and India I presume) is taught to "hack it" at any cost, and we see the results.

Post reply on HN