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

331–340 of 483 posts

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

#331

Post by cestith »

Insanity wrote: post #326
fwip wrote: post #319

Earlier quoted context omitted.

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.

That's a positive interpretation. You might be right, either way that's what I pointed them to. I don't think the LLMs will really replace engineers in the foreseeable future, and so learning the languages and the fundamentals is still needed.

I have a laptop and a phone right here, right now. I have actual calculators around here somewhere. I’ve been out of schools for decades. I still can do arithmetic and basic algebra in my head or on paper and often do.

I’m hoping the situation with LLMs will be the same. Teach the basics and allow people to fall back on them for at least the simpler tasks for their lifetimes. I know people, by the way, who can still use an abacus and a slide rule. I can too, but with a refresher beforehand because I seldom use those.

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

#332

Post by pydry »

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…

Going "what if?" and then validating a customer requirement that exists NOW is NOT the same thing as trying to pre-empt a customer's requirement which might exist in the future.

Audit trails are commonly neglected coz somebody didnt ask the right questions, not coz somebody didnt try to anticipate the future.

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

#333

Post by kshacker »

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…

IMO it is a valid question. Our AI has not yet reached that level, our prompts have not yet reached that level of sophistication. But I do not code in assembly any more, I do not do pointer arithmetic any more, so maybe some day we get to a state where we do not write python also. It is not going to be soon despite the AI bandwagon saying so, there are too many legacy pieces that are not documented well and not easy decipherable due to context window limits. But in 10 years ...maybe prompts is all we need.

PS: Not that we do not have people working at all levels of stack today, just that each level of stack, like a discussion going on today about python's JIT compiler will be a few (dozen or hundred) specialists. Everyone else can work with prompts.

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

#334

Post by 9rx »

fl0ki wrote: post #327
ryguz wrote: post #297

[flagged]

I only agree if you have a bounded dataset size that you know will never grow. If it can grow in future (and if you're not sure, you should assume it can), not only will many data structures and algorithms scale poorly along the way, but they will grow to dominate the bottleneck as well. By the time it no longer meets requirements and you get a trouble ticket, you're now under time pressure to develop, qualify, and d…

> You're much more likely to encounter regressions when doing this under time pressure.

There is nothing to suggest you should wait to optimize under pressure, only that you should optimize only after you have measured. Benchmark tests are still best written during the development cycle, not while running hot in production.

Starting with the naive solution helps quickly ensure that your API is sensible and that your testing/benchmarking is in good shape before you start poking at the hard bits where you are much more likely to screw things up, all while offering a baseline score to prove that your optimizations are actually necessary and an improvement.

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

#335

Post by dreko »

Later never comes" is true, but the fix isn't to optimize early, it's to write code simple enough that optimization is easy when later finally does come. That's what Rule 5 is really about. Get the data structures right and the rest is tractable.

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

#336

Post by munk-a »

ryguz wrote: post #297

[flagged]

As someone who believes strongly in type based programming and the importance of good data structure choice I'm not seeing how Rule 5 follows Rule 1. I think it's important to reinforce how impactful good data structure choice is compared to trying to solve everything through procedural logic since a well structured coordination of data interactions can end up greatly simplifying the amount of standalone logic.

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

#337

Post by CyberDildonics »

JanisErdmanis wrote: post #299
embedding-shape wrote: post #103

Earlier quoted context omitted.

The scope of where that data structure or functions are available is a different concern though, "100 functions + 1 data structure" doesn't require globals or private, it's a separate thing.

One can always look as global variables equivalent to a context object that’s is passed in every function. It’s just a syntactic difference whether one constructs such data structure or uses it implicitly via globals. What I am getting at is that when one has such gigantic data structure there is no separation of concerns.

Does one need one's separation of concerns if one's concerns shouldn't be separated in the in the first place?

Anytime one has access to a database one has access to one large global data structure that one can access from anywhere is a program.

This same concept goes for one's global state in one's game if one is making a game.

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

#338

Post by artyom »

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

I agree with you. "Premature" is the keyword. Bloated software is the result of not having the intention to optimize it at all.

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

#340

Post by munro »

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

It's so true, when specing things I always try to focused on DDL because even the UI will fall into place as well, and a place I see claude opus fail as well when building things.

Post reply on HN