[flagged]
Rob Pike’s Rules of Programming (1989)
351–360 of 483 posts
Re: Rob Pike’s Rules of Programming (1989)
#352Earlier quoted context omitted.
I usually defer this until a PM does the research to highlight that speed is a burning issue. I find 98% of the time that users are clamoring to get something implemented or fixed which isnt speed related so I work on that instead. When I do drill down what I tend to find in the flame graphs is that your scope for making performance improvements a user will actually notice is bottlenecked primarily by I/O not by code…
Even at Google, the tendency is (or was when I was there), to only profile things that we know are consuming a lot of resources (or for sure will), or are hurting overall latency. Also the rule (quote?) says "speed hack", I don't think he is saying ignore runtime complexity totally, just don't go crazy with really complex stuff until you are sure you need it.
That depends on which part of Google. I worked in the hot path of the search queries and there speed was extremely important for everything, they want to do so much there every single query and latency isn't allowed to go up.
Re: Rob Pike’s Rules of Programming (1989)
#353> Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming. I'm a big fan of Data Oriented Design. Once you conceptualize how data is stored and transformed in your program, it just has to be reflected in data structures that make it possible. Modern design approaches ten…
The fundamental tension between nouns and verbs and the attempts to unify them like events have made programming a long art form to study.
It's all use-case and priority-specific, and I think the more varied your experience and more tools you have in the tool belt, the better off you can be to bring the right solution to bear. Of course, then you think you have the right solution in mind (lets say using partitions in postgres for something) but you find the ORM your service is using doesn't support it, then what is "best" becomes not only problem-specific but also tool-specific. Finally, even if you have the best solution and your existing ecosystem supports it but the rest of the engineering staff you have is unfamiliar with it, it may again no longer be "best".
this ladder of problem-fit, ecosystem-fit, staffing-fit is something I have grappled with in my career.
LLMs are only so-so at any of the above (even when including the agent as "staff".)
Re: Rob Pike’s Rules of Programming (1989)
#354Here’s the modern version:
https://grugbrain.dev/
Re: Rob Pike’s Rules of Programming (1989)
#355Rule 3 gets me into trouble with CS majors a lot. I'm an EE by education and entered into SW via the bottom floor(embedded C/ASM) so it was late in my career before I knew the formal definition of big-O and complexity. For most of my career, sticking to rule 3 made the most sense. When the CS major would be annoying and talk about big-O they usually forgot n was tiny. But then my job changed. I started working on dif…
Well it is hedged with the word "fancy". I think a charitable reading is to understand the problem domain. If N is always small then trying to minimize the big-O is just showing off and likely counterproductive in many ways. If N is large, it might be a requirement.
Most people don't need FFT algorithm for multiplying large numbers, Karatsuba's algorithm is fine. But in some domains the difference does matter.
Personally I usually see the opposite effect - people first reach for a too-naive approach and implement some O(n^2) algorithm where it wouldn't have even been more complex to implement something O(n) or O(n log n). And n is almost always small so it works fine, until it blows up spectacularly.
Re: Rob Pike’s Rules of Programming (1989)
#356[flagged]
This comment is fascinating to me, as it indicates an entirely different mindset than mine. I'm much more interested in code readability and maintainabilty (and simplicty and elegance) than performance, unless it's necessary. So I would start by saying everything flows from rule 4 or maybe 5. Rule 1 is a consequence of rule 4 for me.
Maybe it's because the comment you are replying to is from a new account posting paragraphs of LLMese in multiple comments in the same minute. It's unsurprising that soulless LLM output doesn't match your mindset!
Re: Rob Pike’s Rules of Programming (1989)
#357Earlier quoted context omitted.
Does one need one's separation of concerns if one's concerns shouldn't be separated in the in the first place? Anytime one has access to a database one has access to one large global data structure that one can access from anywhere is a program. This same concept goes for one's global state in one's game if one is making a game.
Separation of concerns is still a valid paradigm with a single global datastructure like GUI, Microservice, Database and etc. In such situation one can still seperate concerns via composing the global datastructure from a smaller units and define methods with respect to thoose smaller units. In that way one does not need to wonder whether there are some unattended side effects when calling a function that mutates the…
Seems like one is backpedaling because one was just talking about one's separation of one's concerns and now one is defending one's separation of concerns with respect to one's global data structure.
Re: Rob Pike’s Rules of Programming (1989)
#358This reminds me of a portion of a talk Jonathan Blow gave[1], where he justifies this from a productivity angle. He explains how his initial implementation for virtually everything in Braid used arrays of records, and only after finding bottlenecks did he make changes, because if he had approached every technical challenge by trying to find the optimal data structure and algorithm he would never have shipped. "There'…
> how his initial implementation for virtually everything in Braid used arrays of records
This is me with hash maps.
Re: Rob Pike’s Rules of Programming (1989)
#359Earlier quoted context omitted.
Really need that [flag bot] button added to HN.
It would be easier if we could just block comments from green users. I get that it loses ~.1% of authors who might have made an account to comment on a blogpost of theirs that was posted here. I'd rather have that loss than have to deal with the 99.9% of spam.
TIL green means new. I thought it was special for some reason.
Re: Rob Pike’s Rules of Programming (1989)
#360Seem logical