Rob Pike’s Rules of Programming (1989)

Post by danybittel » Thu, Aug 13, 2020, 7:29 AM UTC

eps wrote: post #136

karmakaze wrote: post #110

Earlier quoted context omitted.

And it is usually quoted out of its context. "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."

It's also often interpreted literally. Premature complex optimization is a bad idea, but simple (read, cheap to code) optimization for common bottleneck patterns is a perfectly reasonable thing to do.

Post by mrighele » Thu, Aug 13, 2020, 7:36 AM UTC

s17n wrote: post #128

rumanator wrote: post #111

Earlier quoted context omitted.

> And yet, I see a whole swath of the industry hyper-focused on various linters/styling/rules. It seems to me that what you're actually seeing is an entire industry trying to eliminate all code-related issues, specially bike-shedding ones. This is patently obvious to anyone who was forced to waste their time in code review iterations discussing, say, where a brace should go and how many spaces someone should have add…

Nobody was ever "forced to waste their time" on this stuff. I have a simple rule - I don't comment on other people's style, and if people comment on my style, I just go with their suggestions. Problem solved.

Post by zelly » Thu, Aug 13, 2020, 7:38 AM UTC

dragontamer wrote: post #22

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.

> 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 Are you sure that std::unordered_map is faster than std::vector? Did you measure? Every time you access an element in std::vector, you also access nearby ones (thanks to L1 cache, as well as CPU-prefetching of in-line data). In contrast, your std::unordered_map or hash-table has almost n…

Post by zimpenfish » Thu, Aug 13, 2020, 8:19 AM UTC

hckr1292 wrote: post #169

zimpenfish wrote: post #167

Earlier quoted context omitted.

> a Redis caching layer and a complex custom lookup scheme Bane of my life. A few gigs ago, they had a global Redis cache, a Redis cache per server, an in-app cache, and then MySQL. Needless to say, there were many, MANY bugs that came down to cache coherency and race conditions between them. [edit: it was a global Redis, not clustered.]

Did we both work at a certain edtech company? Seems oddly specific and exactly how I remember our monolith being structured

Post by account42 » Thu, Aug 13, 2020, 8:42 AM UTC

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.