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

51–60 of 483 posts

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

#51

Post by jacquesm »

Intermernet wrote: post #42
relaxing wrote: post #25

Earlier quoted context omitted.

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

Rob Pike is responsible for many cool things, but Unix isn't one of them. Go is a wonderful hybrid (with its own faults) of the schools of Thompson and Wirth, with a huge amount of Pike. If you'd said Plan 9 and UTF-8 I'd agree with you.

Rob Pike definitely wrote large chunks of Unix while at Bell Labs. It's wrong to say he wrote all of it like the GP did but it is also wrong to diminish his contributions.

Unless you meant to imply that UNIX isn't cool.

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

#52

Post by DaleBiagio »

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…

" 9. It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures."

That's great

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

#53

Post by mosura »

Intermernet wrote: post #39
mosura wrote: post #5

Earlier quoted context omitted.

Perlis is just wrong in that way academics so often are. Pike is right.

Hang on, they mostly agree with each other. I've spoken to Rob Pike a few times and I never heard him call out Perlis as being wrong. On this particular point, Perlis and Pike are both extending an existing idea put forward by Fred Brooks.

Perlis absolutely is not saying the same thing, and as the commenter notes the functional community interpret it in a particularly extreme way.

I would guess Pike is simply wise enough not to get involved in such arguments.

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

#56

Post by pydry »

PaulKeeble wrote: post #23
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…

The number 1 issue Ive experienced with poor programmers is a belief that theyre special snowflakes who can anticipate the future.

It's the same thing with programmers who believe in BDUF or disbelieve YAGNI - they design architectures for anticipated futures which do not materialize instead of evolving the architecture retrospectively in line with the future which did materialize.

I think it's a natural human foible. Gambling, for instance, probably wouldnt exist if humans' gut instincts about their ability to predict future defaulted to realistic.

This is why no matter how many brilliant programmers scream YAGNI, dont do BDUF and dont prematurely optimize there will always be some comment saying the equivalent of "akshually sometimes you should...", remembering that one time when they metaphorically rolled a double six and anticipated the necessary architecture correctly when it wasnt even necessary to do so.

These programmers are all hopped up on a different kind of roulette these days...

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

#57

Post by mchaver »

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…

I find languages like Haskell, ReScript/OCaml to work really well for CRUD applications because they push you to think about your data and types first. Then you think about the transformations you want to make on the data via functions. When looking at new code I usually look for the types first, specifically what is getting stored and read.

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

#59

Post by linhns »

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…

Nice to see Perlis mentioned once in a while. Reading SICP again, still learning new things.

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

#60

Post by hrmtst93837 »

mosura wrote: post #5
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…

Perlis is just wrong in that way academics so often are. Pike is right.

[flagged]
Post reply on HN