17 ms·

Rob Pike’s Rules of Programming (1989)

• sunnyos 7mo ago
  Seem logical
• devcraft41 7mo ago
  [dead]
• embedding-shape 7mo ago
  "Epigrams in Programming" by Alan J. Perlis has a lot more, if you like short snippets of wisdom :) https://www.cs.yale.edu/homes/perlis-alan/quotes.html https://www.cs.yale.edu/homes/perlis-alan/quotes.html > 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. Always preferred Perlis' version, that might be slightly over-used in functional programming to justify all kinds of hijinks, but with some nuance works out really well in practice: > 9. It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures.
  • Intermernet 7mo ago
    I believe the actual quote is: "Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious." -- Fred Brooks, The Mythical Man Month (1975)
    • bfivyvysj 7mo ago
      This is the biggest issue I see with AI driven development. The data structures are incredibly naive. Yes it's easy to steer them in a different direction but that comes at a long term cost. The further you move from naive the more often you will need to resteer downstream and no amount of context management will help you, it is fighting against the literal mean.
      • andsoitis 7mo ago
        > This is the biggest issue I see with AI driven development. The data structures are incredibly naive. Bill Gates, for example, always advocated for thinking through the entire program design and data structures before writing any code, emphasizing that structure is crucial to success.
        • neocron 7mo ago
          Ah Bill Gates, the epitome of good software
          • dotancohen 7mo ago
            Yes, actually. Gates wrote great software. Microsoft is another story.
            • jll29 7mo ago
              And Paul Allen wrote a whole Altair emulator so that they could use an (academic) Harvard computer for their little (commercial) project and test/run Bill Gates' BASIC interpreter on it.
          • andsoitis 7mo ago
            > Ah Bill Gates, the epitome of good software While developing Altair BASIC, his choice of data structures and algorithms enabled him to fit the code into just 4 kilobytes.
        • PaulDavisThe1st 7mo ago
          I'd like to see Gates or anyone else do that for a project that lasts (at least) a quarter century and sees a many-fold increase in CPU speed, RAM availability, disk capacity etc.
      • Intermernet 7mo ago
        Naive doesn't mean bad. 99% of software can be written with understood, well documented data structures. One of the problems with ai is that it allows people to create software without understanding the trade offs of certain data structures, algorithms and more fundamental hardware management strategies. You don't need to be able to pass a leet code interview, but you should know about big O complexity, you should be able to work out if a linked list is better than an array, you should be able to program a trie, and you should be at least aware of concepts like cache coherence / locality. You don't need to be an expert, but these are realities of the way software and hardware work. They're also not super complex to gain a working knowledge of, and various LLMs are probably a really good way to gain that knowledge.
    • mock-possum 7mo ago
      I’m really going to need to see both. There’s a lot of business logic that simply is not encoded in a data storage model.
  • mosura 7mo ago
    Perlis is just wrong in that way academics so often are. Pike is right.
    • Intermernet 7mo ago
      Hang on, they mostly agree with each other. I've spoken to Rob Pike a few times and I never heard him call out Perlis as being wrong. On this particular point, Perlis and Pike are both extending an existing idea put forward by Fred Brooks.
      • mosura 7mo ago
        Perlis absolutely is not saying the same thing, and as the commenter notes the functional community interpret it in a particularly extreme way. I would guess Pike is simply wise enough not to get involved in such arguments.
    • jacquesm 7mo ago
      Perlis is right in the way that academics so often are and Pike is right in the way that practitioners often are. They also happen to be in rough agreement on this, unsurprisingly so.
    • hrmtst93837 7mo ago
      [flagged]
    • AnimalMuppet 7mo ago
      Could you be more specific?
      • mosura 7mo ago
        Promoting the idea of one data structure with many functions contradicts: “If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident.” And: “Use simple algorithms as well as simple data structures.” A data structure general enough to solve enough problems to be meaningful will either be poorly suited to some problems or have complex algorithms for those problems, or both. There are reasons we don’t all use graph databases or triple stores, and rely on abstractions over our byte arrays.
  • rsav 7mo ago
    There's also: >I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships. -- Linus Torvalds
    • mikepurvis 7mo ago
      I think this is sometimes a barrier to getting started for me. I know that I need to explore the data structure design in the context of the code that will interact with it and some of that code will be thrown out as the data structure becomes more clear, but still it can be hard to get off the ground when me gut instinct is that the data design isn't right. This kind of exploration can be a really positive use case for AI I think, like show me a sketch of this design vs that design and let's compare them together.
      • ignoramous 7mo ago
        > This kind of exploration can be a really positive use case for AI I think Not sure if SoTA codegen models are capable of navigating design space and coming up with optimal solutions. Like for cybersecurity, may be specialized models (like DeepMind's Sec-Gemini), if there are any, might? I reckon, a programmer who already has learnt about / explored the design space, will be able to prompt more pointedly and evaluate the output qualitatively. > sometimes a barrier to getting started for me Plenty great books on the topic (: Algorithms + Data Structures = Programs (1976), https://en.wikipedia.org/wiki/Algorithms_%2B_Data_Structures_%3D_Programs https://en.wikipedia.org/wiki/Algorithms_%2B_Data_Structures...
        • mikepurvis 7mo ago
          Yeah key word is exploration. It's not "hey Claude write the design doc for me" but rather, here's two possible directions for how to structure my solution, help me sketch each out a bit further so that I can get a better sense what roadblocks I may hit 50-100 hours into implementation when the cost of changing course is far greater.
  • mpalmer 7mo ago
    Was the "J" short for "Cassandra"? When someone says "I want a programming language in which I need only say what I wish done," give him a lollipop.
  • Hendrikto 7mo ago
    I feel like these are far more vague and less actionable than the 5 Pike rules.
  • DaleBiagio 7mo ago
    " 9. It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures." That's great
  • mchaver 7mo ago
    I find languages like Haskell, ReScript/OCaml to work really well for CRUD applications because they push you to think about your data and types first. Then you think about the transformations you want to make on the data via functions. When looking at new code I usually look for the types first, specifically what is getting stored and read.
    • embedding-shape 7mo ago
      Similarly, that approach works really well in Clojure too, albeit with a lot less concern for types, but the "data and data structures first" principle is widespread in the ecosystem.
      • mchaver 7mo ago
        I've heard good things about Clojure, and it'ss different from what I am used to (bonus points because I like an intellectual challenge), so trying it out is definitely on my todo list.
  • linhns 7mo ago
    Nice to see Perlis mentioned once in a while. Reading SICP again, still learning new things.
    • WillAdams 7mo ago
      There is a matching video series for SICP: https://ocw.mit.edu/courses/6-001-structure-and-interpretation-of-computer-programs-spring-2005/video_galleries/video-lectures/ https://ocw.mit.edu/courses/6-001-structure-and-interpretati... which I found very helpful in (finally) managing to get through that entire text (and do all the exercises).
  • 0xpgm 7mo ago
    Reminded me of this thread between Alan Kay and Rich Hickey where Alan Kay thinks "data" is a bad idea. My interpretation of his point of view is that what you need is a process/interpreter/live object that 'explains' the data. https://news.ycombinator.com/item?id=11945722 https://news.ycombinator.com/item?id=11945722 EDIT: He writes more about it in Quora. In brief, he says it is 'meaning', not 'data' that is central to programming. https://qr.ae/pCVB9m https://qr.ae/pCVB9m
    • christophilus 7mo ago
      I’m with Rich Hickey on this one, though I generally prefer my data be statically typed.
      • 0xpgm 7mo ago
        Sure, static typing adds some sort of process that provides a coarse interpretation of the data.
    • radlad 7mo ago
      Hm, not sure. Data on its own (say, a string of numbers) might be meaningless - but structured data? Sure, there may be ambiguity but well-structured data generally ought to have a clear/obvious interpretation. This is the whole idea of nailing your data structures.
      • 0xpgm 7mo ago
        Yeah, structured data implies some processing on raw data to improve its meaning. Alan Kay seems to want to push this idea to encapsulate data with rich behaviour.
    • gregw2 7mo ago
      Thanks for the pointer to this 2016 dialog! One part of it has interesting new resonance in the era of agentic LLMs: alankay on June 21, 2016 | root | parent | next [–] This is why "the objects of the future" have to be ambassadors that can negotiate with other objects they've never seen. Think about this as one of the consequences of massive scaling ... Nowdays rather than the methods associated with data objects, we are dealing with "context" and "prompts".
  • JanisErdmanis 7mo ago
    With 100 functions and one datastructure it is almost as programming with a global variables where new instance is equivalent to a new process. Doesn’t seem like a good rule to follow.
    • embedding-shape 7mo ago
      The scope of where that data structure or functions are available is a different concern though, "100 functions + 1 data structure" doesn't require globals or private, it's a separate thing.
      • JanisErdmanis 7mo ago
        One can always look as global variables equivalent to a context object that’s is passed in every function. It’s just a syntactic difference whether one constructs such data structure or uses it implicitly via globals. What I am getting at is that when one has such gigantic data structure there is no separation of concerns.
        • CyberDildonics 7mo ago
          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.
          • JanisErdmanis 7mo ago
            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 state.
  • alberto-m 7mo ago
    This quote from “Dive into Python” when I was a fresh graduate was one of the most impacting lines I ever read in a programming book. > Busywork code is not important. Data is important. And data is not difficult. It's only data. If you have too much, filter it. If it's not what you want, map it. Focus on the data; leave the busywork behind.
  • bandrami 7mo ago
    Also basically everything DHH ever said (I stopped using Rails 15 years ago but just defining data relationships in YAML and typing a single command to get a functioning website and database was in fact pretty cool in the oughts).
  • Pxtl 7mo ago
    As much as relational DBs have held back enterprise software for a very long time by being so conservative in their development, the fact that they force you to put this relationship absolutely front-of-mind is excellent.
    • embedding-shape 7mo ago
      I'd personally consider "persistence" AKA "how to store shit" to be a very different concern compared to the data structures that you use in the program. Ideally, your design shouldn't care about how things are stores, unless there is a particular concern for how fast things read/writes.
      • mosura 7mo ago
        Often significant improvements to every aspect of a system that interacts with a database can be made by proper design of the primary keys, instead of the generic id way too many people jump to. The key difficulty is identifying what these are is far from obvious upfront, and so often an index appears adjacent to a table that represents what the table should have been in the first place.
        • embedding-shape 7mo ago
          I guess that might be true also, to some extent. I guess most of the times I've seen something "messy" in software design, it's almost always about domain code being made overly complicated compared to what it has to do, and almost never about "how does this domain data gets written/read to/from a database", although it's very common. Although of course storage/persistence isn't non-essential, just less common problem than the typical design/architecture spaghetti I encounter.
        • Pxtl 7mo ago
          I'm a firm believer in always using an auto-generated surrogate key for the PK because domain PKs always eventually become a pain point. The problem is that doing so does real damage to the ergonomics of the DB. This is why I fundamentally find SQL too conservative and outdated. There are obvious patterns for cross-cutting concerns that would mitigate things like this but enterprise SQL products like Oracle and MS are awful at providing ways to do these reusable cross-cutting concerns consistently.
  • tangus 7mo ago
    Aren't they basically saying opposite things? Perlis is saying "don't choose the right data structure, shoehorn your data into the most popular one". This advice might have made sense before generic programming was widespread; I think it's obsolete.
    • Rygian 7mo ago
      Pike: strongly typed logic is great! Perlin: stringly typed logic is great!
    • embedding-shape 7mo ago
      > Perlis is saying "don't choose the right data structure, shoehorn your data into the most popular one" I don't take it like that. A map could be the right data structure for something people typically reach for classes to do, and then you get a whole bunch of functions that can already operate on a map-like thing for free. If you take a look at the standard library and the data structures of Clojure you'd see this approach taken to a somewhat extreme amount.
  • TYPE_FASTER 7mo ago
    > 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. If I have learned one thing in my 30-40 years spent writing code, it is this.
    • seanalltogether 7mo ago
      I agree. The biggest lesson I try to drive home to newer programmers that join my projects is that its always best to transform the data into the structure you need at the very end of the chain, not at the beginning or middle. Keep the data in it's purest form and then transform it right before displaying it to the user, or right before providing it in the final api for others to consume. You never know how requirements are going to change over the next 5 years, and pure structures are always the most flexible to work with.
      • bluGill 7mo ago
        Related: your business logic should work on metric units. It is a UI concern if the user wants to see some other measurement system. Convert to feet, chains, cubits... or whatever obscure measurement system the user wants at display time. (if you do get an embedded device that reports non-metric units convert when it comes in - you will get a different device in the future that reports different units anyway) You still have to worry about someone using kg when you use g, but you avoid a large class of problems and make your logic easier.
  • dcuthbertson 7mo ago
    But doesn't No. 2 directly conflict with Pike's 5th rule? It seems to me these are all aphorisms that have to be taken with a grain of salt. > 2. Functions delay binding; data structures induce binding. Moral: Structure data late in the programming process.
  • jerf 7mo ago
    As I'm sure more and more people are using AI to document old systems, even just to get a foothold in them personally if they don't intend to share it, here's a hint related to that: By default, if you fire an AI at a programming base, at least in my experience you get the usual documentation you expect from a system: This is the list of "key modules", this module does this, this module does that, this module does the other thing. This is the worst sort of documentation; technically true but quite unenlightening. It is, in the parlance of the Fred Brooks quote mentioned in a sibling comment, neither the "flowchart" nor the "tables"; it is simply a brute enumeration of code. To which the fix is, ask for the right thing. Ask for it to analyze the key data structures (tables) and provide you the flow through the program (the flowchart). It'll do it no problem. Might be inaccurate, as is a hazard with all documentation, but it makes as good a try at this style of documentation as "conventional" documentation. Honestly one of the biggest problems I have with AI coding and documentation is just that the training set is filled to the brim with mediocrity and the defaults are inferior like this on numerous fronts. Also relevant to this conversation is that AI tends to code the same way it documents and it won't have either clear flow charts or tables unless you carefully prompt for them. It's pretty good at doing it when you ask, but if you don't ask you're gonna get a mess. (And I find, at least in my contexts, using opus, you can't seem to prompt it to "use good data structures" in advance, it just writes scripting code like it always does and like that part of the prompt wasn't there. You pretty much have to come back in after its first cut and tell it what data structures to create. Then it's really good at the rest. YMMV, as is the way of AI.)
• kleiba 7mo ago
  I believe the "premature evil" quote is by Knuth, not Hoare?!
  • swiftcoder 7mo ago
    Potentially its by either (or even both independently). Knuth originally attributed it to Hoare, but there's no paper trail to demonstrate Hoare actually coined it first
    • Intermernet 7mo ago
      Turns out that premature attribution is actually the root of all evil...
    • Bengalilol 7mo ago
      Every empirical programmer will, at some point, end up yelling it out loud (too).
• bsenftner 7mo ago
  Obvious. Why the elevation of the obvious?
  • bazoom42 7mo ago
    Definitely not obvious to everybody.
  • DrScientist 7mo ago
    I think for people starting out - rule 5 isn't perhaps that obvious. > 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. If want to solve a problem - it's natural to think about logic flow and the code that implements that first and the data structures are an after thought, whereas Rule 5 is spot on. Conputers are machines that transform an input to an output.
    • mosura 7mo ago
      > If want to solve a problem - it's natural to think about logic flow and the code that implements that first and the data structures are an after thought, whereas Rule 5 is spot on. It is? How can you conceive of a precise idea of how to solve a problem without a similarly precise idea of how you intend to represent the information fundamental to it? They are inseparable.
      • DrScientist 7mo ago
        Obviously they are linked - the question is where do you start your thinking. Do you start with the logical task first and structure the data second, or do you actually think about the data structures first? Let's say I have a optimisation problem - I have a simple scoring function - and I just want to find the solution with the best score. Starting with the logic. for all solutions, score, keep if max. Simple eh? Problem is it's a combinatorial solution space. The key to solving this before the entropic death of the universe is to think about the structure of the solution space.
    • 7mo ago
• catchcatchcatch 7mo ago
  [dead]
• heresie-dabord 7mo ago
  See Tony Hoare: https://news.ycombinator.com/item?id=47325225 https://news.ycombinator.com/item?id=47325225
• tobwen 7mo ago
  Added to AGENTS.md :)
  • wwweston 7mo ago
    How good is your model at picking good data structures? There’s several orders of magnitude less available discussion of selecting data structures for problem domains than there is code. If the underlying information is implicit in high volume of code available then maybe the models are good at it, especially when driven by devs who can/will prompt in that direction. And that assumption seems likely related to how much code was written by devs who focus on data.
    • skydhash 7mo ago
      > There’s several orders of magnitude less available discussion of selecting data structures for problem domains than there is code. I believe that’s what most algorithms books are about. And most OS book talks more about data than algorithms. And if you watch livestream or read books on practical projects, you’ll see that a lot of refactor is first selecting a data structure, then adapt the code around it. DDD is about data structure.
  • ozgrakkurt 7mo ago
    Would be cool to see the live reaction of Rob Pike to this comment
    • andsoitis 7mo ago
      > Would be cool to see the live reaction of Rob Pike to this comment Based on everything public, Pike is deeply hostile to generative AI in general: - The Christmas 2025 incident (https://simonwillison.net/2025/Dec/26/slop-acts-of-kindness/ https://simonwillison.net/2025/Dec/26/slop-acts-of-kindness/) - he's labeled GenAI as nuclear waste (https://www.webpronews.com/rob-pike-labels-generative-ai-nuclear-waste-in-viral-2025-critique/ https://www.webpronews.com/rob-pike-labels-generative-ai-nuc...) - ideologically, he's spent his career chasing complexity reduction, adovcating for code sobriety, resource efficiency, and clarity of thought. Large, opaque, energy-intensive LLMs represent the antithesis.
• CharlieDigital 7mo ago
  I feel like 1 and 2 are only applicable in cases of novelty. The thing is, if you build enough of the same kinds of systems in the same kinds of domains, you can kinda tell where you should optimize ahead of time. Most of us tend to build the same kinds of systems and usually spend a career or a good chunk of our careers in a given domain. I feel like you can't really be considered a staff/principal if you can't already tell ahead of time where the perf bottleneck will be just on experience and intuition.
  • HunterWare 7mo ago
    ROFL, I wish Pike had known what he was talking about. /s ;)
    • CharlieDigital 7mo ago
      Rob Pike and I (and probably most of us) work(ed) on different kind of things. Notice my use of the word "Novelty". I get hired because I'm very good at building specific kinds of systems so I tend to build many variants of the same kinds of systems. They are generally not that different and the ways in which the applications perform are similar. I do not generally write new algorithms, operating systems, nor programming languages. I don't think this is so hard to understand the nuance of Pike's advice and what we "mortals" do in or day-to-day to earn a living.
  • PaulKeeble 7mo ago
    I feel like every time I have expected an area to be the major bottleneck it has been. Sometimes some areas perform worse than I expected, usually something that hasn't been coded well, but generally its pretty easy to spot the computationally heavy or many remote call areas well before you program them. I have several times done performance tests before starting a project to confirm it can be made fast enough to be viable, the entire approach can often shift depending on how quickly something can be done.
    • pydry 7mo ago
      The number 1 issue Ive experienced with poor programmers is a belief that theyre special snowflakes who can anticipate the future. It's the same thing with programmers who believe in BDUF or disbelieve YAGNI - they design architectures for anticipated futures which do not materialize instead of evolving the architecture retrospectively in line with the future which did materialize. I think it's a natural human foible. Gambling, for instance, probably wouldnt exist if humans' gut instincts about their ability to predict future defaulted to realistic. This is why no matter how many brilliant programmers scream YAGNI, dont do BDUF and dont prematurely optimize there will always be some comment saying the equivalent of "akshually sometimes you should...", remembering that one time when they metaphorically rolled a double six and anticipated the necessary architecture correctly when it wasnt even necessary to do so. These programmers are all hopped up on a different kind of roulette these days...
• Mercuriusdream 7mo ago
  never expected it to be a single HTML file so kind of surprised, but straight to the point, to be honest.
  • andsoitis 7mo ago
    KISS
    • epolanski 7mo ago
      Well, even simpler, could've been plain text, every browser supports them.
• anthk 7mo ago
  9front it's distilled Unix. I corrected Russ Cox' 'xword' to work in 9front and I am just a newbie. No LLM's, that's Idiocratic, like the movie; just '9intro.us.pdf' and man pages. LLM's work will never be reproducible by design.
• piranha 7mo ago
  > Rule 5 is often shortened to "write stupid code that uses smart objects". This is probably the worst use of the word "shortened" ever, and it should be more like "mutilated"?
  • andsoitis 7mo ago
    Syntactic sugar is cancer of the semicolon.
    • franktankbank 7mo ago
      Tide goes in tide goes out, can't explain that.
      • paradox460 7mo ago
        Tide goes in, clean laundry comes out
• keyle 7mo ago
  Rule 5 is definitely king. Code acts on data, if the data is crap, you're already lost. edit: s/data/data structure/
  • andsoitis 7mo ago
    … if the data structures are crap. Good software can handle crap data.
    • keyle 7mo ago
      That is not what I meant. I meant crap data structures. Sorry it's late here.
• seedpi 7mo ago
  [flagged]
• DaleBiagio 7mo ago
  The attribution to Hoare is a common error — "Premature optimization is the root of all evil" first appeared in Knuth's 1974 paper "Structured Programming with go to Statements." Knuth later attributed it to Hoare, but Hoare said he had no recollection of it and suggested it might have been Dijkstra. Rule 5 aged the best. "Data dominates" is the lesson every senior engineer eventually learns the hard way.
  • zabzonk 7mo ago
    I've always thought it was Dijkstra - it even sounds Dijkstra-ish.
  • YesThatTom2 7mo ago
    If Dijkstra blamed Knuth it would have been the best recursive joke ever.
    • DaleBiagio 7mo ago
      [dead]
• elcapitan 7mo ago
  Meta: Love the simplicity of the page, no bullshit. Funny handwritten html artifact though: <title> <h1>Rob Pike's 5 Rules of Programming</h1> </title>
  • divbzero 7mo ago
    Yes, I noticed this too. Timeless wisdom in 2128 bytes of handcrafted HTML.
• openclaw01 7mo ago
  [dead]
• doe88 7mo ago
  Great rules, but Rule 3.: WOW, so true, so well enunciated, masterful.
  • bell-cot 7mo ago
    Yes, and I'd say it's more true now than then. Best case, your fancy algorithms are super-sizing code that runs 1% of the time, always kicking more-often-run code out of the most critical CPU caches. Worst case, your fancy algorithms contain security bugs, and the bad guys cash in.
• Devasta 7mo ago
  > "Premature optimization is the root of all evil." This Axiom has caused far and away more damage to software development than the premature optimization ever will.
  • gjadi 7mo ago
    Because people only quote it partially. > 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%.
• Iamkkdasari74 7mo ago
  [flagged]
• nateb2022 7mo ago
  Previous discussion: https://news.ycombinator.com/item?id=15776124 https://news.ycombinator.com/item?id=15776124 (8 years ago, 18 comments)
  • tomhow 7mo ago
    Thanks! Here's the full set: Rob Pike’s Rules of Programming (1989) - https://news.ycombinator.com/item?id=38097031 https://news.ycombinator.com/item?id=38097031 - Nov 2023 (259 comments) Rob Pike’s Rules of Programming (1989) - https://news.ycombinator.com/item?id=24135189 https://news.ycombinator.com/item?id=24135189 - Aug 2020 (323 comments) Rob Pike’s Rules of Programming (1989) - https://news.ycombinator.com/item?id=15776124 https://news.ycombinator.com/item?id=15776124 - Nov 2017 (18 comments) Rob Pike’s Rules of Programming (1989) - https://news.ycombinator.com/item?id=15265356 https://news.ycombinator.com/item?id=15265356 - Sept 2017 (112 comments) Rob Pike’s Rules of Programming (1989) - https://news.ycombinator.com/item?id=7994102 https://news.ycombinator.com/item?id=7994102 - July 2014 (96 comments)
• deleted 7mo ago
  [deleted]
• jcmartinezdev 7mo ago
  Rule 6: Never disagree with AI slop
• igtztorrero 7mo ago
  Rule 4, I have always practiced and demanded of junior programmers, to make algorithms and structures that are simple to understand, for our main user: the one who will modify this code in the future. I believe that's why Golang is a very simple but powerful language.
• anymouse123456 7mo ago
  There are very few phrases in all of history that have done more damage to the project of software development than: "Premature optimization is the root of all evil." First, let's not besmirch the good name of Tony Hoare. The quote is from Donald Knuth, and the missing context is essential. From his 1974 paper, "Structured Programming with go to Statements": "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. 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%." He was talking about using GOTO statements in C. He was talking about making software much harder to reason about in the name of micro-optimizations. He assumed (incorrectly) that we would respect the machines our software runs on. Multiple generations of programmers have now been raised to believe that brutally inefficient, bloated, and slow software is just fine. There is no limit to the amount of boilerplate and indirection a computer can be forced to execute. There is no ceiling to the crystalline abstractions emerging from these geniuses. There is no amount of time too long for a JVM to spend starting. I worked at Google many years ago. I have lived the absolute nightmares that evolve from the willful misunderstanding of this quote. No thank you. Never again. I have committed these sins more than any other, and I'm mad as hell about it.
  • devnullbrain 7mo ago
    > and the missing context is essential. Oh yes, I'd recommend everyone who uses the phrase reads the rest of the paper to see the kinds of optimisations that Knuth considers justified. For example, optimising memory accesses in quicksort.
    • anymouse123456 7mo ago
      Exactly! I wish Knuth would come out and publicly chastise the many decades of abuse this quote has enabled.
      • trey-jones 7mo ago
• Shawn19s83 7mo ago
  [dead]
• tasuki 7mo ago
  The first four are kind of related. For me the fifth is the important – and oft overlooked – one: > 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.
• ta20211004_1 7mo ago
  Can't agree more on 5. I've repeatedly found that any really tricky programming problem is (eventually) solved by iterative refinement of the data structures (and the APIs they expose / are associated with). When you get it right the control flow of a program becomes straightforward to reason about. To address our favorite topic: while I use LLMs to assist on coding tasks a lot, I think they're very weak at this. Claude is much more likely to suggest or expand complex control flow logic on small data types than it is to recognize and implement an opportunity to encapsulate ideas in composable chunks. And I don't buy the idea that this doesn't matter since most code will be produced and consumed by LLMs. The LLMs of today are much more effective on code bases that have already been thoughtfully designed. So are humans. Why would that change?
  • zer00eyz 7mo ago
    > refinement of the data structures (and the APIs they expose / are associated with) I think rule 5 is often ignored by a lot of distributed services. Where you have to make several calls, each with their own http, db and "security" overhead, when one would do. Then these each end up with caching layers because they are "slow" (in aggregate).
    • nostrademons 7mo ago
      If you're doing it right, you start with a centralized service; get the product, software architecture, and data flows right while it's all in one process; and then distribute along architectural boundaries when you need to scale. Very few software services built today are doing it right. Most assume they need to scale from day one, pick a technology stack to enable that, and then alter the product to reflect the limitations of the tech stack they picked. Then they wonder why they need to spend millions on sales and marketing to convince people to use the product they've built, and millions on AWS bills to scale it. But then, the core problem was really that their company did not need to exist in the first place and only does because investors insist on cargo-culting the latest hot thing. This is why software sucks so much today.
      • 7mo ago
• dasil003 7mo ago
  These rules aged well overall. The only change I would make these days is to invert the order. Number 5 is timeless and relevant at all scales, especially as code iterations have gotten faster and faster, data is all the more relevant. Numbers 4 and 3 have shifted a bit since data sizes and performance have ballooned, algorithm overhead isn't quite as big a concern, but the simplicity argument is relevant as ever. Numbers 2 and 1 while still true (Amdahl's law is a mathematical truth after all), are also clearly a product of their time and the hard constraints programmers had to deal with at the time as well as the shallowness of the stack. Still good wisdom, though I think on the whole the majority of programmers are less concerned about performance than they should be, especially compared to 50 years ago.
• treetalker 7mo ago
  I'm not a skilled programmer (but would like to be someday). Would someone kindly resolve what appears to me to be a contradiction between the following? 1(a) Torvalds: "Bad programmers worry about the code. Good programmers worry about data structures and their relationships." 1(b) Pike 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." — versus — 2. Perlis 2: "Functions delay binding; data structures induce binding. Moral: Structure data late in the programming process." --- Ignorant as I am, I read these to advise that I ought to put data structures centrally, first, foremost — but not until the end of the programming process.
  • colechristensen 7mo ago
    That is indeed contradictory and what those things say. Good structure comes from exploring until you understand the problem well AND THEN letting data structure dominate.
  • foltik 7mo ago
    Afaict Perlis is more saying not to expose data layout in the boundaries between abstractions, rather to keep them pure and functional. So not really a contradiction, just Perlis talking about the functional shell and Torvalds/Pike talking about the imperative core.
  • zweifuss 7mo ago
    When you explore a problem, use Python and lists/sets/dictionaries/JSON. Wait with types and specific data structures till you have understanding. Speed of development over speed of execution. When you know what and how to build commit to good data structures. Do the types, structs, classes, Trie, CRDTs, XML, Protobuf, Parquet and whatnot where apropriate. Instrument your program. The efficiency of the final product counts.
• dkarl 7mo ago
  I think it's fine and generous that he credited these rules to the better-known aphorisms that inspired them, but I think his versions are better, they deserve to be presented by themselves, instead of alongside the mental clickbait of the classic aphorisms. They preserve important context that was lost when the better-known versions were ripped out of their original texts. For example, I've often heard "premature optimization is the root of all evil" invoked to support opposite sides of the same argument. Pike's rules are much clearer and harder to interpret creatively. Also, it's amusing that you don't hear this anymore: > Rule 5 is often shortened to "write stupid code that uses smart objects". In context, this clearly means that if you invest enough mental work in designing your data structures, it's easy to write simple code to solve your problem. But interpreted through an OO mindset, this could be seen as encouraging one of the classic noob mistakes of the heyday of OO: believing that your code could be as complex as you wanted, without cost, as long as you hid the complicated bits inside member methods on your objects. I'm guessing that "write stupid code that uses smart objects" was a snappy bit of wisdom in the pre-OO days and was discarded as dangerous when the context of OO created a new and harmful way of interpreting it.
  • zemo 7mo ago
    > but I think his versions are better, they deserve to be presented by themselves, instead of alongside the mental clickbait of the classic aphorisms keeping the historical chain of thinking alive is good, actually
  • Matthyze 7mo ago
    "mental clickbait of the classic aphorisms" is one way to phrase 'attribution"
    • dkarl 7mo ago
      I guess what I mean by that is that Rob Pike was obviously aware that his rules were not as catchy and pithy as the aphorisms he credited, and his only reason for writing his rules was to improve on them by making them more explicit and less prone to user error. But presenting his versions alongside the more catchy ones means that every time people read them, the catchy ones distract attention and remain more memorable than the improved versions.
• ajpaulson 7mo ago
  I think I’m going to copy and paste this directly into my AGENTS.md file!
• _philipalan 7mo ago
  CS Unc remains un-chopped.
• mcdonje 7mo ago
  Very performance focused. Could more accurately be 5 rules of perf. Good list, though.
• d_burfoot 7mo ago
  I don't disagree with these principles, but if I wanted to compress all my programming wisdom into 5 rules, I wouldn't spend 3 out of the 5 slots on performance. Performance is just a component of correctness : if you have a good methodology to achieve correctness, you will get performance along the way. My #1 programming principle would be phrased using a concept from John Boyd: make your OODA loops fast. In software this can often mean simple things like "make compile time fast" or "make sure you can detect errors quickly".
• patwolf 7mo ago
  These rules apply equally well to system architecture. I've been trying to talk our team out of premature optimization (redis cluster) and fancy algorithms (bloom filters) to compensate for poor data structures (database schema) before we know if performance is going to be a problem. Even knowing with 100% certainty that performance will be subpar, requirements change often enough that it's often not worth the cost of adding architectural complexity too early.
  • bob1029 7mo ago
    > Even knowing with 100% certainty that performance will be subpar I think there is value in attempting to do something the "wrong way" on purpose to some extent. I have walked into many situations where I was beyond convinced that the performance of something would suck only to be corrected harshly by the realities of modern computer systems. Framing things as "yes, I know the performance is definitely not ideal in this iteration" puts that monkey in a proper cage until the next time around. If you don't frame it this way up front, you might be constantly baited into chasing the performance monkey around. Its taunts can be really difficult to ignore.
• sayYayToLife 7mo ago
  I suppose this makes me feel a little bit better about a multi-month process that ended up requiring the eight Queens problem. That said management did not quite understand. They thought that I should have known about the bottleneck (Actually I did but I was told not to prematurely optimize) I end up writing the program three times, the final solution was honestly beautiful. Management was not happy. The customer was happy.
• ekjhgkejhgk 7mo ago
  Uuuh doesn't look good that you claim something is important enough to be in your top 5, but then misattribute it.
• thecodemonkey 7mo ago
  Running the same codebase for 10+ years with a small team is what finally made me fully internalize these rules. I've always been a KISS/DRY person but over a decade there are plenty of moments where you're tempted to reach for a fancier database or rewrite something in a trendier stack. What's actually kept things running well at scale is boring, known technologies and only optimizing in the places where it actually matters. We wrote our principles down recently and it basically just reads like Pike's rules in different words: https://www.geocod.io/code-and-coordinates/2025-09-30-development-manifesto/ https://www.geocod.io/code-and-coordinates/2025-09-30-develo...
• andxor 7mo ago
  Great gonna add these to my CLAUDE.md /s
• HardCodedBias 7mo ago
  Heretical opinion: I think that Rob Pike was far more of a wordcel than a shape rotator for a famous computer scientist (which historically were very much on the shape rotator side).
• pdpi 7mo ago
  There's an important property that emerges from rules 3 and 4 — because the simple algorithm is easier to implement correctly, you can test the fancy algorithm for correctness by comparing its output to the simple one.
• publicdebates 7mo ago
  "Rule 6: Don't waste time on syntax highlighting unless you're incompetent."
• yandrypozo 7mo ago
  does _a speed hack_ mean adding time.Sleep() for testing? or it's something else?
• OpenDQV 7mo ago
  Golden rules for sure!
• possiblydrunk 7mo ago
  Optimization usually trades complexity for speed. Complexity hinders debugging and maintenance. Don't optimize unless you have to and not before you know where the bottleneck is. Straightforward common sense advice as long as hardware is not persistently constraining.
• TimLeland 7mo ago
  Take a look at the page title. I guess he didn't follow his own rules for this 100-line HTML file <title> <h1>Rob Pike's 5 Rules of Programming</h1> </title>
  • zahlman 7mo ago
    The page was created by some CS professor at UNC, not by Pike. Pike's rules are from 1989, which is before it was common to publish HTML.
• BTAQA 7mo ago
  Rule 5 is the one that took me longest to internalize. Coming from frontend development into building a full product with a real database, I kept reaching for complex query logic when the real fix was just restructuring the data. Once the schema was right the queries became obvious. Brooks was right 50 years ago and it's still true.
• netbioserror 7mo ago
  This resonates as true, as long as the fundamentals of your tools are there. Picking interpreted languages or browsers as targets shoots you in the foot and sets you magnitudes behind when performance starts to matter. But if you're using a native-compiled language with value- and move-semantics, immutable data, and a composable type system, it's shocking how easy it can be to write obvious, maintainable, fast programs that perform under pressure, even when you're not being clever. Thankfully newer languages like Nim, Odin, and Swift lean hard into value semantics. They drastically reduce the cost of focusing on data structures and writing obvious algorithms. Then, when bottlenecks appear, you can choose to opt into fine-tuning.
• fogzen 7mo ago
  Rule 5 should be rule 1.
• SomaticPirate 7mo ago
  How quaint. I hope Claude/Codex reads this since from what I've heard here I'm not likely to need this rules anymore /s I am curious if anyone has attempted to use codex/claude with something like this in the prompt
• sneedenheimer 7mo ago
  Given that Rob Pike seems to think having a shell script that uses tar is better than having a `-r` flag for cp [1], I wouldn't give much weight to his philosophy of programming :P. [1]: https://wiki.c2.com/?WhatIsNotInPlanNine https://wiki.c2.com/?WhatIsNotInPlanNine
• 01100011 7mo ago
  Rule 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 different things. Suddenly my job started sounding more like a leetcode interview people complain about. Now n really is big and now it really does matter. Keep in mind that Rob Pike comes from a different era when programming for 'big iron' looked a lot more like programming for an embedded microcontroller now.
  • SoftTalker 7mo ago
    My father did some programming in Fortran and Assembly of various flavors. He was always partial to lookup tables where they could replace complicated conditionals or computations. Memory was precious in his day but it could still be worth it if your program did something repeatedly (which most do).
  • kevincox 7mo ago
    I actually disagree with Rule 3! While numbers are usually small being fast on small cases generally isn't as important as performing acceptably on large cases. So I prefer to take the better big-O so that it doesn't slow down unacceptably on real-world edge-case stresses. (The type of workloads that the devs often don't experience but your big customers will.) Of course there is a balance to this, the engineering time to implement both options is an important consideration. But given both algorithms are relatively easy to implement I will default to the one that is faster at large sizes even if it is slower at common sizes. I do suspect that there is an implicit assumption that "fancy" algorithms take longer and are harder to implement. But in many cases both algorithms are in the standard library and just need to be selected. If this post focused on "fancy" in terms of actual time to implement rather than speed for common sizes I would be more inclined to agree with it. I wrote an article about this a while back: https://kevincox.ca/2023/05/09/less-than-quadratic/ https://kevincox.ca/2023/05/09/less-than-quadratic/
    • 7mo ago
• big-chungus4 7mo ago
  Idk about rule 1, in my experience it's usually pretty clear which part of code is slow. Maybe it depends on projects, programming language, etc
• wsesamemr81 7mo ago
  [dead]
• justacatbot 7mo ago
  [flagged]
  • ummonk 7mo ago
    That's Rule 5 no?
    • tartoran 7mo ago
      You're responding to a bot
• antirez 7mo ago
  In programming, the only rule to follow is that there are no rules: only taste and design efforts. There are too many different conditions and tradeoffs: sometimes what is going to be the bottleneck is actually very clear and one could decide to design with that already in mind, for instance.
• GuB-42 7mo ago
  The opposite conclusion can be taken from the premise of rule #1 "You can't tell where a program is going to spend its time" If you can't tell in advance what is performance critical, then consider everything to be performance critical. I would then go against rule #3 "Fancy algorithms are slow when n is small, and n is usually small". n is usually small, except when it isn't, and as per rule #1, you may not know that ahead of time. Assuming n is going to be small is how you get accidentally quadratic behavior, such as the infamous GTA bug. So, assume n is going to be big unless you are sure it won't be. Understand that your users may use your software in ways you don't expect. Note that if you really want high performance, you should properly characterize your "n" so that you can use the appropriate technique, it is hard because you need to know all your use cases and their implications in advance. Assuming n will be big is the easy way! About rule #4, fancy algorithms are often not harder to implement, most of the times, it means using the right library. About rule #2 (measure), yes, you absolutely should, but it doesn't mean you shouldn't consider performance before you measure. It would be like saying that you shouldn't worry about introducing bugs before testing. You should do your best to make your code fast and correct before you start measuring and testing. What I agree with is that you shouldn't introduce speed hacks unless you know what you are doing. Most of performance come from giving it consideration on every step. Avoiding a copy here, using a hash map instead of a linear search there, etc... If you have to resort to a hack, it may be because you didn't consider performance early enough. For example, if took care of making a function fast enough, you may not have to cache results later on. As for #5, I agree completely. Data is the most important. It applies to performance too, especially on modern hardware. To give you an very simplified idea, RAM access is about 100x slower than running a CPU instruction, it means you can get massive speed improvement by making your memory footprint smaller and using cache-friendly data structures.
  • deleted 7mo ago
    [deleted]
  • epolanski 7mo ago
    > If you can't tell in advance what is performance critical, then consider everything to be performance critical. As for rule 2: first you measure.
• fl0ki 7mo ago
  > Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. I get where he's coming from, but I've seen people get this very wrong in practice. They use an algorithm that's indeed faster for small n, which doesn't matter because anything was going to be fast enough for small n, meanwhile their algorithm is so slow for large n that it ends up becoming a production crisis just a year later. They prematurely optimized after all, but for an n that did not need optimization, while prematurely pessimizing for an n that ultimately did need optimization.
  • harry8 7mo ago
    The error here is not understanding the data being transformed. You won't get it right either way if you don't /know/ how big n is going to be. If you can't know, why not? Should you even be coding this at all? Maybe there should be a rule zero. 0) Understand the data on which your data transformation is going to operate. The extent you don't is the extent to which the endeavour is doomed.
• R0m41nJosh 7mo ago
  When I was young I took time to "optimize" my code where it obviously had no impact, like on simple python scripts. It was just by ego, to look smart. I guess the "early optimization" takes are aimed at young developers who want to show their skills on completely irrelecant places. Of course with experience, you start to feel when the straight forward suboptimal code will cause massive performance issued. In this case it's critical to take action up front to avoid the mess. Its called software architecture, I guess.
• shashank-100 7mo ago
  [dead]
• vishnugupta 7mo ago
  I can’t emphasize the importance of rule-5 enough. I learnt about rule-5 through experience before I had heard it was a rule. I used to do tech due diligence for acquisition of companies. I had a very short time, about a day. I hit upon a great time saver idea of asking them to show their DB schema and explain it. It turned out to be surprisingly effective. Once I understood the scheme most of the architecture explained itself. Now I apply the same principle while designing a system.
  • SoftTalker 7mo ago
    Yes, fully agree. Rule 5 has been the center of my approach to designing and writing software for over 30 years now. Fad methodologies and platforms come and go but Rule 5 works as well for me today as it did in 1995.
    • artyom 7mo ago
      I can't agree more. I live and breath by rule #5. Getting competent at it, however, is no joke and takes time.
• nlawalker 7mo ago
  This 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's a third thing [beyond speed and memory] that you might want to optimize for which is much more important than either of these, which is years of your life required per program implementation." This is of course from the perspective of a solo indie game developer, but it's a good and interesting perspective to consider. [1] https://www.youtube.com/watch?v=JjDsP5n2kSM https://www.youtube.com/watch?v=JjDsP5n2kSM
  • Insanity 7mo ago
    It's easy to see this outside of the perspective of a solo game developer. We all have deadlines to manage even in the regular 'corporate world'. And engineering time spent on a problem also translates to an actual cost. It's a good consideration tbh.
  • dgb23 7mo ago
    It's also notable that video games are programs that run for hours and iterate over large sets of very similar entities at 60 frames or more per second repeatedly and often do very similar operations on each of the entities. That also means that "just do an array of flat records" is a very sane default even if it seems brutish at first.
    • quietbritishjim 7mo ago
      I think when he said "just do an array of flat records" he meant as opposed to record of arrays (i.e. row oriented vs column oriented), as opposed to fancy data structures which I think you're assuming he was implying. Separate arrays for each data member are common in game engines exactly because they're good for iterating over, which as you said is common.
      • 7mo ago
• cestith 7mo ago
  Any software developer who hasn’t read _The Practice of Programming_ by Kernighan and Pike should. It’s not that long and much of it is timeless.
  • Insanity 7mo ago
    Yeah, but I doubt many of the newer generation are going to read this. I manage a team of engineers, and one of the recent-ish graduates asked me in our 1-on-1 if it's still worth learning Python given that he can just write prompts. (Python is the language all our tools use). If the next generation doesn't even want to learn a programming language, they're definitely not going to learn how to write _clean_ code. Maybe I'm just overly pessimistic about junior engineers at the moment because of that conversation lol.
    • calepayson 7mo ago
      Junior here. There are still a few of us who value books and documentation. It's a weird time though. Hard to feel confident that you're learning in the correct way. Anyway, I've found that if you want to get a coworker into reading technical books, the best way is with a novel or three. I've had good success with The Martian. The Phoenix Project might work too. Slip them fun books until they've built a habit and then drop The Mythical Man Month on them. :)
      • zahlman 7mo ago
        > Hard to feel confident that you're learning in the correct way. This was hard before, too.
    • LVB 7mo ago
      Here's my optimistic take: the fundamental things that spark joy about learning a novel algorithm, pattern, technique, etc. haven't gone anywhere, and there's no reason to think those things won't continue to be interesting. Furthermore, it seems like reading code isn't going anywhere too soon, and that definitely benefits from clean code. It follows that someone who can actually recognize clean from spaghetti, and tell the LLM to refactor it into XYZ style, is going to be relatively more valuable. Random side note: my teen son has grown up with iPhone-level tech, yet likes and finds my old Casio F91 watch very interesting. I still have faith :)
• ryguz 7mo ago
  [flagged]
  • eru 7mo ago
    > In practice what I see fail most often is not premature optimization but premature abstraction. Compare and contrast https://people.mpi-sws.org/~dreyer/tor/papers/wadler.pdf https://people.mpi-sws.org/~dreyer/tor/papers/wadler.pdf
    • tasuki 7mo ago
      Philip Wadler gave us a sound type system. Rob Pike gave us a programming language for stupid people. Each contributed in their own way, towards different goals.
      • eru 7mo ago
        Interestingly, Philip Wadler also worked on the generics in Go, I think?
  • rob 7mo ago
    Really need that [flag bot] button added to HN.
    • tech_hutch 7mo ago
      Are you saying the parent comment seems like a bot?
      • macintux 7mo ago
        Comment history is suspect.
    • rd 7mo ago
      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.
• tracker1 7mo ago
  Pretty much live by these in practice... I've had a lot of arguments over #3 though... yes nested loops can cause problems... but when you're dealing with < 100 or so items in each nested loop and outer loop, it's not a big deal in practice. It's simpler and easier to reason with... don't optimize unless you really need to for practical reasons. On #5, I think most people tend to just lean on RDBMS databases for a lot of data access patterns. I think it helps to have some fundamental understandings in terms of where/how/why you can optimize databases as well as where it make sense to consider non-relational (no-sql) databases too. A poorly structured database can crawl under a relatively small number of users.
• jkaptur 7mo ago
  It's interesting to contrast "Measure. Don't tune for speed until you've measured" with Jeff Dean's "Latency Numbers Every Programmer Should Know" [0]. Dean is saying (implicitly) that you can estimate performance, and therefore you can design for speed a priori - without measuring, and, indeed, before there is anything to measure. I suspect that both authors would agree that there's a happy medium: you absolutely can and should use your knowledge to design for speed, but given an implementation of a reasonable design, you need measurement to "tune" or improve incrementally. 0: https://gist.github.com/jboner/2841832 https://gist.github.com/jboner/2841832
  • eschneider 7mo ago
    I mean...you should always design with speed in mind (In that Jeff Dean sense :) but what 'premature optimization' is referring to, is more like localized speed optimizations/hacks. Don't do those until a) you know you'll need it and b) you know where it will help.
  • sifar 7mo ago
    Yeah, the latency numbers provide a ceiling for your algorithm. The actual performance depends on the implementation, code generation, runtime hazards, small dependencies one may have overlooked etc.
  • SatvikBeri 7mo ago
    I've had the pleasure of working with some truly fast pieces of code written by experts. It's always both. You have to have a good sense of what's generally fast and what's not in order to design a system that doesn't contain intractable bottlenecks. And once you have a good design you can profile and optimize the remaining constraints. But e.g. if you want to do fast math, you really need to design your pipeline around cache efficiency from the beginning – it's very hard to retrofit. Whereas reducing memory allocations in order to make parallel algorithms faster is something you can usually do after profiling.
• PaulHoule 7mo ago
  The "bottleneck" model of performance has limitations. There are a lot of systems where useless work and other inefficiencies are spread all over the place. Even though I think garbage collection is underrated (e.g. Rustifarians will agree with me in 15 years) it's a good example because of the nonlocality that profilers miss or misunderstand. You can make great prop bets around "I'll rewrite your Array-of-Structures code to Structure-of-Arrays code and it will get much faster" https://en.wikipedia.org/wiki/AoS_and_SoA https://en.wikipedia.org/wiki/AoS_and_SoA because SoA usually is much more cache friendly and AoS makes the memory hierarchy perform poorly in a way profilers can't see. The more time somebody spends looking at profilers and more they quote Rule 1 the more they get blindsided by it.
• andrewmcwatters 7mo ago
  [dead]
• okamiueru 7mo ago
  Rule 1 seems similar to Donald Knuths "premature optimization" from 1974. > Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. 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%. Rule 2 follows rule 1. Rule 3 & 4 is a variation of Keep it Simple, Stupid (KISS) from the 1960s. ... and... now I feel stupid, because I read the last part, which is summarizing it in the same way.
• dreko 7mo ago
  Later never comes" is true, but the fix isn't to optimize early, it's to write code simple enough that optimization is easy when later finally does come. That's what Rule 5 is really about. Get the data structures right and the rest is tractable.
• seedpi 7mo ago
  [flagged]
• munro 7mo ago
  > 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. It's so true, when specing things I always try to focused on DDL because even the UI will fall into place as well, and a place I see claude opus fail as well when building things.
  • cleaver 7mo ago
    I recall a similar statement from Ed Yourdon in one of his books (90's?)
    • EvanAnderson 7mo ago
      The article makes reference to Fred Brooks and "The Mythical Man Month", but doesn't make a direct quote. The quote I'd have referenced is: "Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious." -- Fred Brooks, The Mythical Man Month (1975)
• oxag3n 7mo ago
  > 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 tend to focus on choosing a right abstraction like columnar/row layout, caching etc. They mostly fail to optimally work with the data. Optimal in this case meaning getting most of all underlying hardware capabilities, for example reading large and preferably continuous blocks of data from magnetic storage, parallel data processing, keeping intermediate results in CPU caches, utilizing all physical SSD queues.
  • aaronblohowiak 7mo ago
    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".)
• ryguz 7mo ago
  [flagged]
• makeitrain 7mo ago
  Here’s the modern version: https://grugbrain.dev/ https://grugbrain.dev/
• awesome_dude 7mo ago
  I received some 'interesting' feedback when I spoke about commenting that I was using an O(n) search instead of an O(log n) algorithm because of the normally small size of n [0] What I should have done was point to Rob's third rule (either in my comment or in the resulting threads) [0] https://news.ycombinator.com/threads?id=awesome_dude&next=47314703#47303759 https://news.ycombinator.com/threads?id=awesome_dude&next=47...
• IvyMike 7mo ago
  Once upon a time in the 90's I was at work at 2am and I needed to implement a search over a data set. This function was going to be eventually called for every item, thus if I implemented it as a linear search, it would be n^2 behavior. Since it was so late and I was so tired, I marked it as something to fix later, and just did linear search. Later that week, now that things were working, I profiled the n^2 search. The software controlled a piece of industrial test equipment, and the actual test process would take something around 4 hours to complete. Using the very worst case, far-beyond-reasonable data set, if I left the n^2 behavior in, would have added something like 6 seconds to that 4 hour runtime. (Ultimately I fixed it anyways, but because it was easy, not because it mattered.)
  • senderista 7mo ago
    For small enough n, linear search might have been faster.
    • deleted 7mo ago
      [deleted]
  • bsder 7mo ago
    The problem with O(n^2) algorithms is that they are fast enough to get into production and slow enough to explode in production.
• jancsika 7mo ago
  Can you actually follow rule #1 for things like realtime audio programming?
• riclib 7mo ago
  [dead]
• eichin 7mo ago
  Heh, in the early days of C++ (1990ish) I had a notable application of 3+4 involving a doubly linked list with cache pointers (time-sequence data browser so references were likely "nearby" as the user zoomed in; spec was to handle streaming data eventually.) Had problems with it crashing in pointer-related ways (in 1990, nobody had a lot of C++ experience) so I cooked up a really dumb "just realloc an array" version so I could figure out if the problem was above or below data structure... and not only didn't the "dumb" version crash, it was also much faster (and of faster order!) due to amortized realloc - doing a more expensive operation much less often turns out to be a really good trick :-)
• rsc 7mo ago
  Worth noting these were not written as rules of programming generally but rules specifically targeted at complexity. They are lifted from the "Complexity" section of Rob's "Notes on Programming in C". https://www.lysator.liu.se/c/pikestyle.html https://www.lysator.liu.se/c/pikestyle.html http://www.literateprogramming.com/pikestyle.pdf http://www.literateprogramming.com/pikestyle.pdf
• wei03288 7mo ago
  [dead]
• maxothex 7mo ago
  [dead]
• up2isomorphism 7mo ago
  Even agree with most of the stuff he said, however in real life, you won't be able to win a fight using these arguments. You can only create a environment to execute these strategies first to get a good product and them use them as a propaganda afterwards.
• nelsonfigueroa 7mo ago
  > Data structures, not algorithms, are central to programming I'm a big time leetcode interview hater and reading that felt validating. Why the f*ck am I always asked about algorithms.
  • throwway262515 7mo ago
    [dead]
• piskov 7mo ago
  > Pike's rules 1 and 2 restate Tony Hoare's famous maxim "Premature optimization is the root of all evil." This thing never resonated with me. I often hear it as an excuse to ignore “optimization” at all. It’s like “broken windows” theory. This allows slop, rot, and technical debt in. And it spreads fast. Also if everything is unoptimized, this is not what could be easily fixed. Death of thousand cuts, if you will.
• neonsunset 7mo ago
  [dead]
• kinnth 7mo ago
  I used this with Claude to cross compare against my current project and it found 11 pretty significant improvements. Very awesome set of prompts for the ai to then work on.
• apf6 7mo ago
  In a world of AI coding I think rule 5 is still as important than ever. I don’t validate everything Claude does but I do put attention on data structure design since it’s so important.
• mnkyprskbd 7mo ago
  Rob Pike is programming God of retardmaxxing. Go programming language is a good example of this, where it was the dumbest language for a longgg time.
• unit149 7mo ago
  [dead]
• userbinator 7mo ago
  Rule 5 doesn't seem to get a lot of attention but I've refactored many complicated nested branchy functions into a table over the years, and it almost always improves speed, size, and ease of future modification.
• m463 7mo ago
  Wonder how many premature optimizations choose C/C++ over python?
• nsnzjznzbx 7mo ago
  Electron.js took this concept a bit too far.
• ____tom____ 7mo ago
  "N is usually small" might need to be revisited.
• zz1528774295 7mo ago
  [dead]
• harryt 7mo ago
  Nate B Jones mentioned this: https://www.youtube.com/watch?v=7AO4w4Y_L24 https://www.youtube.com/watch?v=7AO4w4Y_L24 when i saw this video i realized i saw this on hacker news too. love how these fundamentals still hold up in the age of AI