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

301–310 of 332 posts

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

#301

Post by pjettter »

bob1029 wrote: post #144

Modeling the problem domain is so important that I dont know why the first year of every compsci undergrad program isnt entirely dedicated to teaching the idea. Instead, day 1 is installing python or java, running hello world and talking about pointers, binary, encoding, logic gates, etc. We should be teaching students on day 1 that code is a liability and to be avoided whenever it is convenient to do so.

I recommend Domain Modeling Made Functional by Scott Wlaschin. It's analaysis first, DDD, then coding (in F#) Best intro to functional programming imo.

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

#302

Post by pitay »

maxk42 wrote: post #133
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…

This is particularly exasperating for me. I can't tell you how many times in my professional career I've ended up speeding up systems by removing two or three layers of improperly-implemented "caching" and using good ol' MySQL and a basic understanding of algorithmic time complexity to simplify things.

My problem was people using ORM frameworks and having very little knowledge of the database they were using. Slow as molasses, difficult to figure out what is going on because of many layers of extra "stuff".

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

#303

Post by mgkimsal »

lokar wrote: post #152
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…

This. The point of the style guide, now reaching its best embodiment in clang-format, gofmt, and others, is that you don't want to waste time arguing about, or even considering for a moment the formatting of anything.

the people who might not follow explicit guides are also the ones who don't typically spend the time 'arguing' about it in the first place though.

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

#304

Post by rumanator »

Aeolun wrote: post #273
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…

Doing any kind of style discussion in a code review means you’ve already failed. I personally get super annoyed when people keep pointing out style issues, but our CI tool can notify me of issues with my commit until the end of time without me getting frustrated with it.

> Doing any kind of style discussion in a code review means you’ve already failed

This sort of baseless assertion has no bearing in reality. In a project that hasn't adopted any linting tools and automatic style checks, all it takes is a misconfigured editor to post a change request that fails to comply with style guides. These sorts of absolutes show a complete detachment from reality and absence of any practical experience in the field.

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

#305

Post by dragontamer »

avasthe wrote: post #220
dragontamer wrote: post #61

Earlier quoted context omitted.

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…

> sorted std::vector But inserting into sorted std::vector is o(n log n) in worst case right? (As you have to binary search the position and move other elements). But a hash set with linear probing can give O(1) (amortized) access, while usually maintaining an invariant like total_size > 2*n. I don't think that would be such an impact on cache locality. Linear probing doesn't require linked lists. Of course this is g…

Yeah, linear probing helps hash-sets a lot on modern CPUs.

Perhaps linear probing is a better example of how BigO analysis can go wrong on modern architectures. Inserting into a hashset with linear-probing is O(n) worst-case, while inserting into a linked list is always O(1) (best case, worst case, and average case).

And yet, linear probing seems to work out best in practice (with a bit of rigging. The total_size > 2*n invariant is one, but so does Robin-hood hashing if you want to keep the table small)

Linear probing vs Linked List implementations of hash-sets seems to be a more clear example of an O(1) vs O(n) anomaly, where the O(n) example is superior.

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

#306

Post by oh-4-fucks-sake »

thdrdt wrote: post #237
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…

It is all about lack of knowledge because checking where the bottlenecks are is one thing. Knowing why they are there is another. A retailer app was very slow. The developers proposed a newer faster server with a newer Oracle version. Then I took a look at one of the slowest queries. Changed it so it could use the indexes in a better way and the query went from +20 to 0.7 seconds. The developers measured the query wa…

I've had many similar experiences with Postgres. I always seem to be the one adding the query logging to the apps. Then I feed the prod queries into the query planner. Then run the results through this tool: http://tatiyants.com/pev/#/plans/new Tweak the queries, add/remove indexes. Voilà.

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

#307

Post by oh-4-fucks-sake »

maxk42 wrote: post #133
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…

This is particularly exasperating for me. I can't tell you how many times in my professional career I've ended up speeding up systems by removing two or three layers of improperly-implemented "caching" and using good ol' MySQL and a basic understanding of algorithmic time complexity to simplify things.

Same boat. Basically every day.

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

#308

Post by avasthe »

dragontamer wrote: post #305
avasthe wrote: post #220

Earlier quoted context omitted.

> sorted std::vector But inserting into sorted std::vector is o(n log n) in worst case right? (As you have to binary search the position and move other elements). But a hash set with linear probing can give O(1) (amortized) access, while usually maintaining an invariant like total_size > 2*n. I don't think that would be such an impact on cache locality. Linear probing doesn't require linked lists. Of course this is g…

Yeah, linear probing helps hash-sets a lot on modern CPUs. Perhaps linear probing is a better example of how BigO analysis can go wrong on modern architectures. Inserting into a hashset with linear-probing is O(n) worst-case, while inserting into a linked list is always O(1) (best case, worst case, and average case). And yet, linear probing seems to work out best in practice (with a bit of rigging. The total_size > 2…

I don't think it is the same thing.

Inserting into linked list assumes you have found the node to insert in.

I don't remember exact details but in hash set with linear probing, the worst case happens quite rarely given the hash function is good one (which are quite sophisticated these days). It is O(1) amortized. The same applies for hash table with chaining too, that all of your keys may go to same bucket given a sufficiently bad hash function.

Given the other choices, like (as far as I know) SkipList based or tree based variants, hash sets are obvious choice.

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

#309

Post by byronr »

gridlockd wrote: post #257
zimpenfish wrote: post #171

Earlier quoted context omitted.

> 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(!)…

Writeup of the blit terminal's operating system is here, it consists of a lot more than the bitblt primitive, with many whole-system performance concerns at play:

http://a.papnet.eu/UNIX/bltj/06771910.pdf

Suggest you read this before denigrating Rob Pike's bona fides. Not sure what axe you are trying to grind but it is ugly and unbecoming of a professional.

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

#310

Post by avasthe »

coldtea wrote: post #261
avasthe wrote: post #214

Earlier quoted context omitted.

This is taken to other extreme many times. Example: Google Chrome codebase was allocating lot of std::string and also someone used a Set to check membership of single item. [1] I mean, if you say like this, many people don't even care about algorithm complexity. Doesn't help that people want to write Python in the monster that is C++. https://groups.google.com/a/chromium.org/forum/m/#!msg/chrom...

> and also someone used a Set to check membership of single item. [1] Depending on where it was done (fast path or not), this could be just fine.

You don't know when something comes to hot path.

    if (std::set(itr.begin(), itr.end()).count(element)) { _____ }
is it tempting for someone than something like

std::find(itr.begin(), itr.end(), element) != itr.end())

?? I don't know. That said, C++ STL quite undiscoverable.

Post reply on HN