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

251–260 of 332 posts

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

#251

Post by indiv0 »

aprdm wrote: post #180
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.

Please tell me you have git LFS configured to handle this.

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

#252

Post by account42 »

erik_seaberg wrote: post #98
atombender wrote: post #79

Earlier quoted context omitted.

Not all optimization candidates are about bottlenecks. Reducing allocation is also optimization, for example.

Peak memory or garbage collection throughput can become a bottleneck. But if you know you have more memory than you need, further reducing allocation is arguably a waste of your time. This can become a tragedy of the commons in desktop and mobile apps, where you don't know how much memory the end user has or needs, but you do know you aren't paying for it.

> But if you know you have more memory than you need, further reducing allocation is arguably a waste of your time.

This is absolutely not true. Just because you have enough memory does not mean that wasted memory couldn't be better used - e.g. for disk cache or to run more tasks.

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

#253

Post by disgruntledphd2 »

codemonkey-zeta wrote: post #193
triangleman wrote: post #172

Earlier quoted context omitted.

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

Magit with emacs solves git's UX problem IMO. Discoverability is/was git's real problem.

This is true, but the trouble is that you need to know what git will do before the magit commands and options make sense.

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

#254

Post by account42 »

zelly wrote: post #244
terandle wrote: post #7

Am I wrong to avoid writing O(n^2) code if at all possible when it is fairly easy to use hash tables for a better time complexity? Sure when n is small the O(n^2) one will be faster but when n is small /anything/ you do is fast in absolute terms so I'm trying to not leave traps in my code just waiting for n to get bigger than initially expected.

Refer to the rule about measuring first. It's a pessimisation because N may not even be large enough to overcome the slowdown from a hash table's cache misses. You can always profile and fix it later.

You can never profile with all data your users are going to feed the program.

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

#255

Post by account42 »

dragontamer wrote: post #61
krzat wrote: post #45

Earlier quoted context omitted.

Worrying about performance of small collections is premature optimization. Using maps or sets nowadays is mostly for clarity, as they are used to solve certain kind of problems.

I agree with you. But what you're talking about is completely different from what I was responding to originally. If you need a set, use a set. But don't assume that its faster than a std::vector. Even then, std::vector has set-like operations through binary_search or std::make_heap in C++, so it really isn't that hard using a sorted (or make_heap'd) std::vector in practice. -------- Even if you don't plan on doing o…

> Even then, std::vector has set-like operations through binary_search or std::make_heap in C++, so it really isn't that hard using a sorted (or make_heap'd) std::vector in practice.

Except std::vector does not enforce the sorted or heap constraints when adding or removing elements so eventually someone working on your code will break them.

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

#256

Post by goto11 »

codetrotter wrote: post #158
johnisgood wrote: post #130

Earlier quoted context omitted.

> I just go with their suggestions. Why though? I am not going to go with suggestions if they make the code less readable for me!

I think the whole world would benefit if we’d make it so that code formatting happened separately from what was committed. Then everyone could have their local checkouts formatted the way they wanted and there would be nothing to argue about in terms of coding style.

Why though? It seems like an elaborate technical solution just to avoid someone making a decision on fruitless bike-shedding discussions. It will only work for white space formatting not for other conventions prone to bikeshedding like naming/casing conventions.

Just make decision and get on with your lives. Have some kind of linter check for inconsistencies before any human review.

If an organization cannot make a decision on inconsequential bike-shedding it is dysfunctional.

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

#257

Post by gridlockd »

zimpenfish wrote: post #171
gridlockd wrote: post #154

Earlier quoted context omitted.

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 believ…

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

I've looked into in that. Blit was monochrome, had an 8Mhz processor, and a relatively large 256KB framebuffer which could but directly written to. There were only a handful commands, mostly concerned with copying (blitting) bitmaps around.

Rob Pike only wrote the first version of the graphics routines - the slowest version, in C(!). It was rewritten another four times over, by Locanthi and finally Reiser.

I don't think any credit should go to Pike for implementing the performance-critical parts of that system.

https://9p.io/cm/cs/doc/87/archtr.ps.gz

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

No, it doesn't mean that. You can be wasteful on constrained hardware as well, performance doesn't necessarily matter even on the simplest chips, if what you want to do doesn't need the full capabilities of the system.

However, I am specifically replying to the claim that "Rob Pike probably knows a thing or two about performance". As you can see, Rob Pike handed off performance-critical work to someone else. He probably didn't know how to write optimal code for that particular platform, but even if he did, most of that knowledge wouldn't transfer over to modern systems.

At the very least, he didn't care about optimizing that stuff, or he wouldn't have handed it off. He would've enjoyed optimizing that stuff. And that's all completely fine, not every programmer needs to care about performance. I just refuse to take advice from these people about performance or "premature optimization", because it is uninformed.

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

#258

Post by [deleted] »

mturmon wrote: post #230
gridlockd wrote: post #154

Earlier quoted context omitted.

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…

Your reply here saddens me. I suggest you look up Rob Pike and reconsider some of your hypotheticals about what he knows about. ( https://en.wikipedia.org/wiki/Rob_Pike )

[deleted]

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

#259

Post by Joker_vD »

karmakaze wrote: post #121
aserafini wrote: post #105

Earlier quoted context omitted.

Sometimes storing in UTC is simply not correct. For example a shop opening time. The shop opens 10am local time, whether DST or not. Their opening time is 10am local time all year but their UTC opening time actually changes depending on the time of year!

The most interesting case of this I encountered was for photo 'timestamps' on a global sharing site. UTC was being used and I was proposing a change to local time. There was great debate as many drank the UTC juice and stopped thinking. It was when I showed them that we also have a 'shot at' location then proceeded to show Christmas eve photos showing the UTC time converted to the viewers local timezone (not always e…

For historical events, where the local time is important, the combination of "UTC timestamp" and "local time offset in effect at the moment the timestamp was taken" seems to be the choice. Allows you to easily learn what time the wall clock was showing at the moment.

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

#260

Post by Joker_vD »

wtetzner wrote: post #123
aserafini wrote: post #105

Earlier quoted context omitted.

Sometimes storing in UTC is simply not correct. For example a shop opening time. The shop opens 10am local time, whether DST or not. Their opening time is 10am local time all year but their UTC opening time actually changes depending on the time of year!

But a shop opening time is not a timestamp, so I think the original advice is still good. A timestamp is the time at which some event happened, which is different than a date/time used for specifying a schedule. For example, if you wanted to track the history of when the shop actually opened, it would make sense to store a UTC timestamp.

And the time offset that was in effect when the event happened, allows you to easily answer questions like "Did the shop open late, i.e. after 10 AM local time?".
Post reply on HN