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

231–240 of 483 posts

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

#231

Post by lokar »

rob74 wrote: post #224
lokar wrote: post #220

Earlier quoted context omitted.

Another thought: many (most?) of these "rules" were before widespread distributed computing. I don't think Knuth had in mind a loop that is reading from a database at 100ms each time. I've seen people write some really head shaking code that makes remote calls in a loop that don't actually depend on each other. I wonder to what extend they are thinking "don't bother with optimization / speed for now"

If you really have a loop that is reading from a database at 100ms each time, that's not because of not having optimized it prematurely, that's just stupid.

And yet... :)

I think there is just a current (I've seen it mostly in Jr engineers) that you should just ignore any aspect of performance until "later"

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

#232

Post by BTAQA »

Rule 5 is the one that took me longest to internalize. Coming from frontend development into building a full product with a real database, I kept reaching for complex query logic when the real fix was just restructuring the data. Once the schema was right the queries became obvious. Brooks was right 50 years ago and it's still true.

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

#233

Post by trgn »

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

A lot of developers get enamored by fetishes. Just one example, because it's one i always struggle to vanquish in any of my teams.

Devs are obsessed with introducing functional-style constructs everywhere, just for the sake of it. FP is great for some classes of software, but baseline crufty for anything that requires responsiveness (front-ends basically), let alone anything at real interactive speeds (games, geo-software, ...)

The "premature optimization" quote is then always used as a way to ignore that entire code paths will be spamming the heap with hundreds of thousands of temporary junk, useless lexical scopes, and so forth. Writing it lean the first time is never considered, because of adherence to these fetishes (mutability is bad, oo is bad, loops lead to off-by-one errors, ...). It's absolutely exhausting to have these conversations, it's always starting from the ground up and these quotes like "premature optimization is the root of all evil" are only used as invocations to ward of criticism.

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

#234

Post by netbioserror »

This resonates as true, as long as the fundamentals of your tools are there. Picking interpreted languages or browsers as targets shoots you in the foot and sets you magnitudes behind when performance starts to matter. But if you're using a native-compiled language with value- and move-semantics, immutable data, and a composable type system, it's shocking how easy it can be to write obvious, maintainable, fast programs that perform under pressure, even when you're not being clever.

Thankfully newer languages like Nim, Odin, and Swift lean hard into value semantics. They drastically reduce the cost of focusing on data structures and writing obvious algorithms. Then, when bottlenecks appear, you can choose to opt into fine-tuning.

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

#235

Post by [deleted] »

bluGill wrote: post #184
trey-jones wrote: post #148

Earlier quoted context omitted.

DRY is not to avoid writing code (of any amount). DRY is a maintainability feature. "Unless you're very familiar with the code" you probably won't remember that you have to make this change in two places instead of one. DRY makes life easier for future you, and anyone else unfortunate to encounter (y)our mess.

You are confusing DRY done as intended vs what DRY looks like in the real world to many people.

[deleted]

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

#236

Post by chuckadams »

colechristensen wrote: post #225
trey-jones wrote: post #148

Earlier quoted context omitted.

DRY is not to avoid writing code (of any amount). DRY is a maintainability feature. "Unless you're very familiar with the code" you probably won't remember that you have to make this change in two places instead of one. DRY makes life easier for future you, and anyone else unfortunate to encounter (y)our mess.

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...

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

#237

Post by bdangubic »

Megranium wrote: post #185
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,…

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" ...

> Make it work first, THEN make it work fast

1. I have seen too many "make it work first" that ended up absolute shitshow that was notoriously difficult to do anything with. You can build the software right the first time

2. The "fast" part is what I think too many people are focusing on and in my experience the "THEN" part is always missing resources utilization and other types of inefficiency that are not necessarily related to speed. I have seen absolute messes of software that work really fast

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

#239

Post by lokar »

lokar wrote: post #231
rob74 wrote: post #224

Earlier quoted context omitted.

If you really have a loop that is reading from a database at 100ms each time, that's not because of not having optimized it prematurely, that's just stupid.

And yet... :) I think there is just a current (I've seen it mostly in Jr engineers) that you should just ignore any aspect of performance until "later"

and, I guess, context does matter. If you need to make 10 calls to gather up some info to generate something, but you only need to do this once a day, or hour, and if the whole process takes a few seconds that's fine, I could see the argument that just doing the calls one at a time linearly is simpler write/read/maintain.

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

#240

Post by rco8786 »

Megranium wrote: post #185
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,…

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" ...

Ditto here
Post reply on HN