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

21–30 of 483 posts

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

#21

Post by mpalmer »

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…

Was the "J" short for "Cassandra"?

    When someone says "I want a programming language in which I need only say what I wish done," give him a lollipop.

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

#22

Post by mosura »

pjc50 wrote: post #15
bsenftner wrote: post #6

Obvious. Why the elevation of the obvious?

You've got to elevate some obviously correct things, otherwise social media will fill the void with nonobviously incorrect things.

Better to have 100 comments on one topic than 10 comments on 10 topics.

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

#23

Post by PaulKeeble »

CharlieDigital wrote: post #18

I feel like 1 and 2 are only applicable in cases of novelty. The thing is, if you build enough of the same kinds of systems in the same kinds of domains, you can kinda tell where you should optimize ahead of time. Most of us tend to build the same kinds of systems and usually spend a career or a good chunk of our careers in a given domain. I feel like you can't really be considered a staff/principal if you can't alre…

I feel like every time I have expected an area to be the major bottleneck it has been. Sometimes some areas perform worse than I expected, usually something that hasn't been coded well, but generally its pretty easy to spot the computationally heavy or many remote call areas well before you program them.

I have several times done performance tests before starting a project to confirm it can be made fast enough to be viable, the entire approach can often shift depending on how quickly something can be done.

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

#24

Post by pm215 »

praptak wrote: post #14
bsenftner wrote: post #6

Obvious. Why the elevation of the obvious?

A good chunk of great advice is obvious things that people still fail to do . That's why a collection of "obvious" things formulated in a convincing way by a person with big street cred is still useful and worth elevating.

Also, "why these 5 in particular" is definitely not obvious -- there are a great many possible "obvious in some sense but also true in an important way" epigrams to choose from (the Perlis link from another comment has over a hundred). That Pike picked these 5 to emphasise tells you something about his view of programming, and doubly so given that they are rather overlapping in what they're talking about.

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

#25

Post by relaxing »

CharlieDigital wrote: post #18

I feel like 1 and 2 are only applicable in cases of novelty. The thing is, if you build enough of the same kinds of systems in the same kinds of domains, you can kinda tell where you should optimize ahead of time. Most of us tend to build the same kinds of systems and usually spend a career or a good chunk of our careers in a given domain. I feel like you can't really be considered a staff/principal if you can't alre…

Rob Pike wrote Unix and Golang, but sure, you’re built different.

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

#27

Post by wwweston »

tobwen wrote: post #13

Added to AGENTS.md :)

How good is your model at picking good data structures?

There’s several orders of magnitude less available discussion of selecting data structures for problem domains than there is code.

If the underlying information is implicit in high volume of code available then maybe the models are good at it, especially when driven by devs who can/will prompt in that direction. And that assumption seems likely related to how much code was written by devs who focus on data.

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

#28

Post by HunterWare »

CharlieDigital wrote: post #18

I feel like 1 and 2 are only applicable in cases of novelty. The thing is, if you build enough of the same kinds of systems in the same kinds of domains, you can kinda tell where you should optimize ahead of time. Most of us tend to build the same kinds of systems and usually spend a career or a good chunk of our careers in a given domain. I feel like you can't really be considered a staff/principal if you can't alre…

ROFL, I wish Pike had known what he was talking about. /s ;)

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

#29

Post by anthk »

9front it's distilled Unix. I corrected Russ Cox' 'xword' to work in 9front and I am just a newbie. No LLM's, that's Idiocratic, like the movie; just '9intro.us.pdf' and man pages.

LLM's work will never be reproducible by design.

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

#30

Post by andsoitis »

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.

> This is the biggest issue I see with AI driven development. The data structures are incredibly naive.

Bill Gates, for example, always advocated for thinking through the entire program design and data structures before writing any code, emphasizing that structure is crucial to success.

Post reply on HN