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

321–330 of 332 posts

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

#321

Post by swift532 »

zelly wrote: post #240
OliverJones wrote: post #81

In long-lived systems (systems that run for many years) it's almost impossible to choose the "right data structures" for the ages. The sources and uses of your data will not last nearly as long as the data itself. What to do about this? Two things: STORE YOUR TIMESTAMPS IN UTC. NOT US Pacific or any other local timezone. If you start out with the wrong timezone you'll never be able to fix it. And generations of progr…

> STORE YOUR TIMESTAMPS IN UTC. NOT US Pacific or any other local timezone. What difference does it make if the timestamp includes the timezone? The UTC value can be recovered. In some applications the timezone is useful e.g. when intraday times matter.

Daylight savings might get in the way, especially if daylight savings rules change some time later.

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

#322

Post by flukus »

bernawil wrote: post #316
noisy_boy wrote: post #222

Earlier quoted context omitted.

Having worked with Hibernate recently on a smallish database (that isn't expected to grow too big), my take away is to minimize the network trips. If you have to check something for a list/set of things and all of that can be done from, say, two not so big tables, fetch the superset of records via a join with as much criteria pushed to predicates as efficiently possible and handle rest of the logic in application cod…

Not to cache simple trips to the database is pretty uncontroversial, the are more controversial cases elsewhere. Say you consume a Restful API to hidrate order data in another system. Do you fetch orders as: /orders?ids=id-1,id-2,id-3 or separate calls to /orders/id-x which can be cached and retrieved by id as a memoized function? Well if you had to pick only one the second is probably better, but the best would be a…

If this is a common occurrence the former would almost always be better, the second would be absolutely glacial.

> but the best would be abstracting away order fetching in application code to always fetch single orders and behind the scenes looking up the cache for singles and pooling all the misses into a single request to the plural endpoint.

Unless a significant amount of requests have 100% cache hits then I doubt a local cache will make much of a difference at all, all it's saving is a bit of bandwidth.

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

#323

Post by dvfjsdhgfv »

dkarl wrote: post #272
dvfjsdhgfv wrote: post #242

Earlier quoted context omitted.

> It looks like an excellent candidate to put it entirely in RAM and trigger sync on writes only, why on Earth would you need anything else.

That's effectively what MySQL is going to do.

For the most part, yes, but I was thinking about explicitly proloading all tables and indexes into RAM or even using the MEMORY engine, if it makes sense in that particular case.

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

#324

Post by wtetzner »

munificent wrote: post #138

> 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 agree with the general thrust of this. But it's worth pointing out that often the easiest way to prove where a bottleneck is (or at least) isn't, is to try an optimization and see if it helps. I like prof…

I think the point is more to direct how you write/refactor code: focus more on the data structures than on the code. E.g. if you're struggling to write the code, then maybe you need to take a step back and reconsider your data structures.

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

#325

Post by dnautics »

bluGill wrote: post #290
dnautics wrote: post #122

Earlier quoted context omitted.

I disagree. You code your algo for one input, come up with a corner case, write a failing test, refactor, repeat. For an algo, let's say it operates on a list, I'll start with test f([]) == 0, and implement f to output the constant 0. And then go from there.

That only works if the algorithm isn't already understood and so you don't know what optimal is. If you tdd sort there is no way to get divide the list to small chunks, insert sort each small chunk, then merge sort them. (20 years ago this is what gnu sort did, I assume that this algorithm has changed now that cache is a bigger factor in performance). Even knowing that the above is your end goal TDD to get there is w…

Ok but honestly, most people are not coding raw low level data structure algorithms. They are coding business algorithms. "Here's a table of accounts, calculate what they owe"

When one says "wide range of inputs", as gp did, one is not talking about low-level algorithms; one is talking about a business algorithm. You should be using TDD for this.

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

#326

Post by Quekid5 »

rumanator wrote: post #229
Quekid5 wrote: post #150

Earlier quoted context omitted.

Just out of morbid curiosity... have you actually experienced multiple 'seniors' giving conflicting code review comments about code style (of all things)? That sounds quite dysfunctional. (EDIT: Sure, nitpicks may differ, but...)

> That sounds quite dysfunctional. No,it doesn't. It sounds like the expected outcome of not enforcing an established style with automated tools. All it takes is someone posting a merge request with a bracket out of place, or tabs instead of spaces which screws layout because yes IDEs have custom definitions and a dude happened to have opened a source file with an editor that wasn't properly configured. Boom, merge r…

> It sounds like the expected outcome of not enforcing an established style with automated tools.

Unfortunately those also have significant downsides around large-scale refactoring.

What I always do (and advise other code reviewers to do) is to just ask themselves: Does this code follow the local style in the file being edited?

That simplifies things greatly, IME.

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

#327

Post by Quekid5 »

jacobsenscott wrote: post #153
Quekid5 wrote: post #148

Earlier quoted context omitted.

This usually a good time to apply the When In Rome rule. Do not reformat needlessly, follow the code style of the code you're modifying. Done. (If multiple people are arguing back and forth in code review -- when following the WIR rule -- tell them about the WIR rule and that should settle it. If not, you have bigger problems in your team.)

Sort of. You shouldn't combine style and non-style changes in on change set. But if your project has mixed styles from file to file you should assimilate the locals over time, just as the Romans did. A consistent style has value.

I agree (in principle!) with the idea that consistency across the whole code base has value, but personally I find it extremely marginal, unless you're literally dealing with e.g. hundreds of people needing to read/modify the code. The value proposition skews heavily towards situations where you have a lot of people needing to read/modify the code.

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

#328

Post by tikiman163 »

tonyhb wrote: post #189
vvanders wrote: post #177

Earlier quoted context omitted.

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.

The other rule is choose your data structures wisely.

The number of people who don't understand when to use a list/array VS dictionary/hash table vs lookup object is too damn high. A huge amount of basic optimization is constantly at their fingertips and they nearly always choose to make a list/array and use linq to join/merge multiple relational data sets instead of optimized standard objects.

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

#329

Post by formerly_proven »

projektfu wrote: post #196
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…

Architecture is not optimization. This gets fuzzy with the decision to use caching, static generation, etc. Ideally, redis or memcached can be added when needed. It will require some changing of the app but hopefully in limited places. This rule a la Pike is about doing things like writing assembly or manually unrolling loops in noncritical parts of code. However, in some code, almost everything is on the critical pa…

Latency and throughput are not the same thing. A CPU can process multiple instructions per clock cycle yet instructions take longer than a clock cycle.

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

#330

Post by wtetzner »

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.

Sorry, I was replying to this:

> The counter argument would be that git is the poster-child of poor UX, which could be blamed on the fact that it exposes too much of its internal data structure and general inner-workings to the user.

I agree with you that the UI is inconsistent, however I don't agree that it's the result of git exposing too much of the internal data structure.

Post reply on HN