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

311–320 of 483 posts

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

#311

Post by LVB »

Insanity wrote: post #298
cestith wrote: post #294

Any software developer who hasn’t read _The Practice of Programming_ by Kernighan and Pike should. It’s not that long and much of it is timeless.

Yeah, but I doubt many of the newer generation are going to read this. I manage a team of engineers, and one of the recent-ish graduates asked me in our 1-on-1 if it's still worth learning Python given that he can just write prompts. (Python is the language all our tools use). If the next generation doesn't even want to learn a programming language, they're definitely not going to learn how to write _clean_ code. May…

Here's my optimistic take: the fundamental things that spark joy about learning a novel algorithm, pattern, technique, etc. haven't gone anywhere, and there's no reason to think those things won't continue to be interesting. Furthermore, it seems like reading code isn't going anywhere too soon, and that definitely benefits from clean code. It follows that someone who can actually recognize clean from spaghetti, and tell the LLM to refactor it into XYZ style, is going to be relatively more valuable.

Random side note: my teen son has grown up with iPhone-level tech, yet likes and finds my old Casio F91 watch very interesting. I still have faith :)

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

#312

Post by CharlieDigital »

HunterWare wrote: post #28
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 ;)

Rob Pike and I (and probably most of us) work(ed) on different kind of things.

Notice my use of the word "Novelty".

I get hired because I'm very good at building specific kinds of systems so I tend to build many variants of the same kinds of systems. They are generally not that different and the ways in which the applications perform are similar.

I do not generally write new algorithms, operating systems, nor programming languages.

I don't think this is so hard to understand the nuance of Pike's advice and what we "mortals" do in or day-to-day to earn a living.

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

#313

Post by wduquette »

Insanity wrote: post #298
cestith wrote: post #294

Any software developer who hasn’t read _The Practice of Programming_ by Kernighan and Pike should. It’s not that long and much of it is timeless.

Yeah, but I doubt many of the newer generation are going to read this. I manage a team of engineers, and one of the recent-ish graduates asked me in our 1-on-1 if it's still worth learning Python given that he can just write prompts. (Python is the language all our tools use). If the next generation doesn't even want to learn a programming language, they're definitely not going to learn how to write _clean_ code. May…

In almost forty years of experience, the fraction of developers I've known who read in the field beyond what's strictly needed for their task is very small. I'm always delighted when I find one.

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

#314

Post by okamiueru »

Rule 1 seems similar to Donald Knuths "premature optimization" from 1974.

> Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

Rule 2 follows rule 1.

Rule 3 & 4 is a variation of Keep it Simple, Stupid (KISS) from the 1960s.

... and... now I feel stupid, because I read the last part, which is summarizing it in the same way.

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

#315

Post by CharlieDigital »

tbrownaw wrote: post #193
pydry wrote: post #56

Earlier quoted context omitted.

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…

Sure, don't build your system to keep audit trails until after you have questions to answer so that you know what needs to go in those audit trails. Don't insist on file-based data ingestion being a wrapper around a json-rpc api just because most similar things are moving that direction; what matters is whether someone has specifically asked for that for this particular system yet. . Not all decisions can be usefully…

    > Sure, don't build your system to keep audit trails until after you have questions to answer so that you know what needs to go in those audit trails...what matters is whether someone has specifically asked for that for this particular system yet.
I spent ~15 years in life sciences.

You're going to build an audit trail, no matter what. There's no validated system in LS that does not have an audit trail.

It's just like e-commerce; you're going to have a cart and a checkout page. There's no point in calling that a premature optimization. Every e-commerce website has more or less the same set of flows with simply different configuration/parameters/providers.

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

#316

Post by 9rx »

amw-zero wrote: post #306
9rx wrote: post #106

Earlier quoted context omitted.

Are you under the impression he was, like, a hands-off project manager or something? His involvement was in writing it. Not singlehandedly, but certainly as part of a team. He unquestionably wrote it. He did not envision it like he did the other projects you mention, but the original credit was only in the writing of.

To say "Rob Pike wrote Unix" is completely inaccurate. He joined after v7, in 1980.

Nobody seems to be questioning that he was involved in Unix. Given that he didn't write it, what did he do for the project? Quality assurance? Support? Marketing? Court jester?

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

#318

Post by dgb23 »

nlawalker wrote: post #293

This reminds me of a portion of a talk Jonathan Blow gave[1], where he justifies this from a productivity angle. He explains how his initial implementation for virtually everything in Braid used arrays of records, and only after finding bottlenecks did he make changes, because if he had approached every technical challenge by trying to find the optimal data structure and algorithm he would never have shipped. "There'…

It's also notable that video games are programs that run for hours and iterate over large sets of very similar entities at 60 frames or more per second repeatedly and often do very similar operations on each of the entities.

That also means that "just do an array of flat records" is a very sane default even if it seems brutish at first.

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

#319

Post by fwip »

Insanity wrote: post #298
cestith wrote: post #294

Any software developer who hasn’t read _The Practice of Programming_ by Kernighan and Pike should. It’s not that long and much of it is timeless.

Yeah, but I doubt many of the newer generation are going to read this. I manage a team of engineers, and one of the recent-ish graduates asked me in our 1-on-1 if it's still worth learning Python given that he can just write prompts. (Python is the language all our tools use). If the next generation doesn't even want to learn a programming language, they're definitely not going to learn how to write _clean_ code. May…

I obviously wasn't there, but it sounds like maybe they were asking for reassurance. There's a lot of people out there saying that LLMs are going to totally replace regular programming, and for a new grad who doesn't know much about the world, they value your expertise.

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

#320

Post by SoftTalker »

01100011 wrote: post #252

Rule 3 gets me into trouble with CS majors a lot. I'm an EE by education and entered into SW via the bottom floor(embedded C/ASM) so it was late in my career before I knew the formal definition of big-O and complexity. For most of my career, sticking to rule 3 made the most sense. When the CS major would be annoying and talk about big-O they usually forgot n was tiny. But then my job changed. I started working on dif…

My father did some programming in Fortran and Assembly of various flavors. He was always partial to lookup tables where they could replace complicated conditionals or computations. Memory was precious in his day but it could still be worth it if your program did something repeatedly (which most do).
Post reply on HN