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

441–450 of 483 posts

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

#441

Post by strix_varius »

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 you can't really be considered a staff/principal if you can't already tell ahead of time where the perf bottleneck will be just on experience and intuition.

/s right?

What a red flag that would be!

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

#443

Post by FarmerPotato »

gspr wrote: post #118
aljgz wrote: post #108

Earlier quoted context omitted.

In all honesty, this is one of the less abused quotes, and I have seen more benefit from it than harm. Like you, I've seen people produce a lot of slow code, but it's mostly been from people who would have a really hard time writing faster code that's less wrong. I hate slow software, but I'd pick it anytime over bogus software. Also, generally, it's easier to fix performance problems than incorrect behavior, especia…

> I have seen more benefit from it than harm. Same. I, too, am sick of bloated code. But I use the quote as a reminder to myself: "look, the fact that you could spend the rest of the workday making this function run in linear instead of quadratic time doesn't mean you should – you have so many other tasks to tackle that it's better that you leave the suboptimal-but-obviously-correct implementation of this one little…

yes! See Rule 4

/* If we can cache this partial result, and guarantee that the cache stays coherent across updates, then average response time will converge on O(log N) instead of O(N). But first make the response pass all the unit tests today */

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

#444

Post by [deleted] »

wild_egg wrote: post #416
MaxBarraclough wrote: post #404

Earlier quoted context omitted.

Jonathan Blow's own unreleased Jai programming language has a feature to make it trivial to switch between array-of-structs and struct-of-arrays. From a quick search, it seems HackerNews's own jcelerier has put together a C++ library for doing this. https://github.com/celtera/ahsohtoa

Zig also makes this trivial

[deleted]

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

#445

Post by apitman »

akoboldfrying wrote: post #428
hugey010 wrote: post #375

Earlier quoted context omitted.

Premature abstraction is one of the worst pitfalls when writing software. It's paid for up front, it costs developer time to understand and work with, it adds complexity (tech debt), increases likeliness of bugs, and increases refactor time. All for someone to say "if we ever want to do X". If we wanted to do it, we'd do it now. I truly believe this comes from devs who want to feel smart by "architecting" solutions t…

I think it mostly happens because a little bit of abstraction is nearly always uncontroversially good. If you want to print a line of text 5 times, you'll instinctively write a for loop to do it, instead of copy-pasting the original print() statement an extra 4 times. The cognitive overhead upon reading this code is near zero, since we're all so familiar with it. This is abstraction, nonetheless. So a little bit is a…

Reminds me of:

https://www.brandons.me/blog/write-code-not-too-much-mostly-...

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

#446

Post by eru »

tasuki wrote: post #397
eru wrote: post #301

Earlier quoted context omitted.

> In practice what I see fail most often is not premature optimization but premature abstraction. Compare and contrast https://people.mpi-sws.org/~dreyer/tor/papers/wadler.pdf

Philip Wadler gave us a sound type system. Rob Pike gave us a programming language for stupid people. Each contributed in their own way, towards different goals.

Interestingly, Philip Wadler also worked on the generics in Go, I think?

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

#447

Post by 9rx »

jacquesm wrote: post #177
relaxing wrote: post #146

Earlier quoted context omitted.

I did not say he wrote all of it. “Write” can include co-authorship. A lot of people are learning some history today, beautiful to see.

I think that if you meant co-authorship you could have made that clearer. A 'contributed to' would have saved some unique ids.

> I think that if you meant co-authorship you could have made that clearer.

What lead you to believe until now that Unix was written by just one person?

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

#450

Post by jpc0 »

akkad33 wrote: post #347
munk-a wrote: post #336

Earlier quoted context omitted.

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.

But good data structure is not always evident from the get go. And if your types are too specific it would make future development hard if the specs change. This is what I struggle with

Good strong (read specific) types encourage easier redactors.

Changing the function signature or the type then generated cascade of compiler errors that tells you exactly what you touched.

Weak non specific types does not have that property and even with tests you cannot be sure about the change and cannot even be sure you are upholding invariants

Post reply on HN