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

161–170 of 483 posts

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

#161

Post by bluGill »

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

Don't confuse premature pessimization for the warnings against premature optimization.

I can write bubble sort, it is simple and I have confidence it will work. I wrote quicksort for class once - I turned in something that mostly worked but there were bugs I couldn't fix in time (but I could if I spent more time - I think...)

However writing bubble sort is wrong because any good language has a sort in the standard library (likely timsort or something else than quicksort in the real world)

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

#162

Post by Kye »

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…

As always, xkcd:

https://xkcd.com/1205/

https://xkcd.com/974/

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

#163

Post by embedding-shape »

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.

> Perlis is saying "don't choose the right data structure, shoehorn your data into the most popular one"

I don't take it like that. A map could be the right data structure for something people typically reach for classes to do, and then you get a whole bunch of functions that can already operate on a map-like thing for free.

If you take a look at the standard library and the data structures of Clojure you'd see this approach taken to a somewhat extreme amount.

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

#164

Post by embedding-shape »

mosura wrote: post #153
embedding-shape wrote: post #90

Earlier quoted context omitted.

I'd personally consider "persistence" AKA "how to store shit" to be a very different concern compared to the data structures that you use in the program. Ideally, your design shouldn't care about how things are stores, unless there is a particular concern for how fast things read/writes.

Often significant improvements to every aspect of a system that interacts with a database can be made by proper design of the primary keys, instead of the generic id way too many people jump to. The key difficulty is identifying what these are is far from obvious upfront, and so often an index appears adjacent to a table that represents what the table should have been in the first place.

I guess that might be true also, to some extent. I guess most of the times I've seen something "messy" in software design, it's almost always about domain code being made overly complicated compared to what it has to do, and almost never about "how does this domain data gets written/read to/from a database", although it's very common. Although of course storage/persistence isn't non-essential, just less common problem than the typical design/architecture spaghetti I encounter.

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

#165

Post by ndriscoll »

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.

IME doing application servers and firmware my whole career, simple and fast are usually the same thing, and "simple secure" is usually better security posture than "complex secure".

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

#166

Post by tikhonj »

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…

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 started thinking about code in these terms, I realized that questions like "DRY vs YAGNI" were not meaningful.

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

#167

Post by nostrademons »

bfivyvysj wrote: post #19
Intermernet wrote: post #3

Earlier quoted context omitted.

I believe the actual quote is: "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." -- Fred Brooks, The Mythical Man Month (1975)

This is the biggest issue I see with AI driven development. The data structures are incredibly naive. Yes it's easy to steer them in a different direction but that comes at a long term cost. The further you move from naive the more often you will need to resteer downstream and no amount of context management will help you, it is fighting against the literal mean.

The rule may not hold with AI driven development. The rule exists because it's expensive to rewrite code that depends on a given data structure arrangement, and so programmers usually resort to hacks (eg. writing translation layers or views & traversals of the data) so they can work with a more convenient data structure with functionality that's written later. If writing code becomes free, the AI will just rewrite the whole program to fit the new requirements.

This is what I've observed with using AI on relatively small (~1000 line) programs. When I add a requirement that requires a different data structure, Claude will happily move to the new optimal data structure, and rewrite literally everything accordingly.

I've heard that it gets dicier when you have source files that are 30K-40K lines and programs that are in the million+ line range. My reports have reported that Gemini falls down badly in this case, because the source file blows the context window. But even then, they've also reported that you can make progress by asking Gemini to come up with the new design, and then asking it to come up with a list of modules that depend upon the old structure, and then asking it to write a shim layer module-by-module to have the old code use the new data structure, and then have it replace the old data structure with the new one, and then have it remove the shim layer and rewrite the code of each module to natively use the new data structure. Basically, babysit it through the same refactoring that an experienced programmer would use to do a large-scale refactoring in a million+ line codebase, but have the AI rewrite modules in 5 minutes that would take a programmer 5 weeks.

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

#168

Post by taneq »

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…

“Once, twice, automate/abstract” is a good general rule but you have to understand that the thing you’re counting isn’t appearances in the source code, it’s repetitions of the same logic in the same context. It’s gotta mean the same, not just look the same.

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

#169

Post by taneq »

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…

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

Exactly.

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

#170

Post by embedding-shape »

ndriscoll wrote: post #165
embedding-shape wrote: post #112

Earlier quoted context omitted.

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.

IME doing application servers and firmware my whole career, simple and fast are usually the same thing, and "simple secure" is usually better security posture than "complex secure".

Interesting, never done firmware, but plenty of backends and frontends. Besides the whole "do less and things get faster", I can't think of a single case where "simple" and "fast" is the same thing.

And I'd agree that "simple secure" is better than "complex secure" but you're kind of side-stepping what I said, what about "not secure at all", wouldn't that lead to simpler code? Usually does for me, especially if you have to pile it on top of something that is already not so secure, but even when taking it into account when designing from ground up.

Post reply on HN