Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rob Pike’s Rules of Programming (1989)

users.ece.utexas.edu

Post reply on HN
Print view View original

171–180 of 332 posts

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

#171

Post by zimpenfish »

gridlockd wrote: post #154
byronr wrote: post #149

Earlier quoted context omitted.

> Rob Pike probably has never written a program where performance really mattered Rob Pike has written window system software which ran in what now would be called a "thin client" over a 9600 baud modem and rendered graphics using a 2MHz CPU. He probably knows a thing or two about performance tuning.

By "rendered graphics" you mean "place characters on screen"? If the bottleneck for that is a 9600 baud modem throughput, there's not a lot you need to optimize, even on a 2MHZ CPU. Also, having programmed more constrained systems decades ago doesn't magically make you knowledgeable on performance on modern hardware with completely different capabilities. In fact, it's probably what causes you to develop a "computers…

> By "rendered graphics" you mean "place characters on screen"?

It was a fully graphical 800x1024 (or 1024x1024) system running on 1982 processors.

https://en.wikipedia.org/wiki/Blit_(computer_terminal)

> having programmed more constrained systems decades ago doesn't magically make you knowledgeable on performance

Perhaps not but it does mean you've "written a program where performance really mattered" which I believe was the original claim?

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

#172

Post by triangleman »

rabidrat wrote: post #127
wtetzner wrote: post #124

Earlier quoted context omitted.

Or perhaps learning Git just requires a different approach: you understand the model first, not the interface. Once you understand the model (which is quite simple), the interface is easy.

People keep repeating this, but it's not true. The interface has so many "this flag in this case" but "this other flag in that case" and "that command doesn't support this flag like that" etc. There's no composability or orthoganality or suggestiveness. It's nonsensical and capricious and unmemorable, even though I understand the "simple" underlying model and have for years.

Has anyone attempted to re-engineer a superior UX on top of the git data structure? Would it even be possible?

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

#173

Post by mlvljr »

rumanator wrote: post #119
Koshkin wrote: post #99

Earlier quoted context omitted.

That’s why in C++ we have traits and overloading.

Could you explain where do you see traits and overloading helping you with floating point operations?

He will - when you fail his phone screen :) Kidding.

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

#174

Post by zimpenfish »

nurettin wrote: post #60

These rules look silly when you know that your tight loop that waits for IO or redundantly computes things needs caching. No, you don't need to measure that, and you know that your tight loop function is going to be the bottleneck. Everyone knows that. Now it does make sense when you introduce an entire constraint library instead of looping over 3-4 variables with a small search space. But again, you know it is a sma…

> No, you don't need to measure that

Just this evening I came across some code which pasted an image on top of a blue background (in Go) that set every individual pixel to the background, then got every pixel from the source and set the corresponding pixel of the destination to that colour. I figured it'd be quicker to paste the source onto the destination with `image/draw`.

Turns out, if you're using NRGBA images, it's 40-50% slower. That's definitely an "obvious optimisation" that was proven wrong by measurement.

(If you're using RGBA images, though, the pasting method is 300% faster. Because obviously.)

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

#175

Post by molodec »

mywittyname wrote: post #11

> "write stupid code that uses smart objects". Writing stupid code is actually really difficult. For me, it takes a little bit of iterating before I know just the right place to insert stupid.

Why does it have to be this polarized - stupid code & smart objects. Writing smart code that uses smart objects is better than stupid code. Writing stupid code that uses smart objects is indeed difficult.

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

#176

Post by keithnz »

TeMPOraL wrote: post #165
dkarl wrote: post #126

> Rule 1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is. I wish people would follow this rule and just let stuff work. I recently encountered the most extreme version of this I've ever seen in my career: a design review where a guy proposed a Redis caching layer…

That case you've seen speaks of the guy's inexperience and lack of understanding. I have a problem with this rule because what I see happening is people taking it to heart and no longer thinking about what they're doing performance-wise. And then the program is working 1000x slower than it should, at no extra gain (and often a loss) of readability or safety, just because someone decided to use O(n) data structure whe…

I think maybe you are misreading the rule, it doesn't say don't optimize, it says when optimizing, don't guess from the code where the bottleneck is, go measure it.

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

#177

Post by vvanders »

keithnz wrote: post #176
TeMPOraL wrote: post #165

Earlier quoted context omitted.

That case you've seen speaks of the guy's inexperience and lack of understanding. I have a problem with this rule because what I see happening is people taking it to heart and no longer thinking about what they're doing performance-wise. And then the program is working 1000x slower than it should, at no extra gain (and often a loss) of readability or safety, just because someone decided to use O(n) data structure whe…

I think maybe you are misreading the rule, it doesn't say don't optimize, it says when optimizing, don't guess from the code where the bottleneck is, go measure it.

Yeah but some things like how you structure your data(which then drives CPU cache misses) aren't something you can easily adjust/tune.

Usually when you encounter one of those it's a rewrite/rearchitecture of a whole module/subsystem before you see any gains. Been there done that, not excited to repeat it again.

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

#178

Post by furyofantares »

mgkimsal wrote: post #93
monocasa wrote: post #71

Earlier quoted context omitted.

Resaid by Linus with a bit more modern nomeclature (and Linus's trademark bluntness): > Bad programmers worry about the code. Good programmers worry about data structures and their relationships

> Bad programmers worry about the code And yet, I see a whole swath of the industry hyper-focused on various linters/styling/rules.

> > Bad programmers worry about the code

> And yet, I see a whole swath of the industry hyper-focused on various linters/styling/rules.

I've come to a severe distaste for this good programmer/bad programmer mentality I've seen on the internet for, I guess decades now

There is skill in programming, yes, obviously. But this simplistic divide seems to me to be more about putting one's own ego on the superior side. It leads to simplistic heuristics and flames rather than nuanced discussion

In this case, in my opinion, linters/styling/rules help people to focus on what matters. And sure, with sufficient skill you might not need any of that to help you focus on what matters. But so what? It's better if we can make the trade more accessible, and can make it so people can focus on what matters with less experience

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

#180

Post by aprdm »

dkarl wrote: post #126

> Rule 1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is. I wish people would follow this rule and just let stuff work. I recently encountered the most extreme version of this I've ever seen in my career: a design review where a guy proposed a Redis caching layer…

hehehhe I have actually put some data that do not change more often than once a week hardcoded in the code base and commited in source control... whenever a change needs to happen in the data the CI/CD runs and deploys a new version of the app.

You don't wanna know how that was done before. It is like < 1 GB of JSON as well.

Post reply on HN