I had exactly this discussion today in an architectural discussion about an infrastructure extension today. As our newest team member noted, we planned to follow the reference architecture of a system in some places, and chose not to follow the reference architecture in other places.

And this led to a really good discussion pulling the reference architecture of this system apart and understanding what it optimizes for (resilience and fault tolerance), what it sacrifices (cost, number of systems to maintain) and what we need. And yes, following the reference architecture in one place and breaking it in another place makes sense.

And I think that understanding the different options, as well as the optimization goals setting them apart, allows you to make a more informed decision and allows you to make a stronger argument why this is a good decision. In fact, understanding the optimization criteria someone cares about allows you to avoid losing them in topics they neither understand nor care about.

For example, our CEO will not understand the technical details why the reference architecture is resilient, or why other choices are less resilient. And he would be annoyed about his time being wasted if you tried. But he is currently very aware of customer impacts due to outages. And like this, we can offer a very good argument to invest money in one place for resilience, and why we can save money in other places without risking a customer impact.

We sometimes follow rules, and in other situations, we might not.

I often Bang on about “software is a new form of literacy”. And this I feel is a classic example - software is a form of literacy that not only can be executed by a CPU but also at the same time is a way to transmit concepts from one humans head to another (just like writing)

And so asking “will AI generated code help” is like asking “will AI generated blog spam help”?

No - companies with GitHub copilot are basically asking how do I self-spam my codebase

It’s great to get from zero to something in some new JS framework but for your core competancy - it’s like outsourcing your thinking - always comes a cropper

(Book still being written)

> My goal in most cases now is to optimize code for the limits of the human mind (my own in low-effort mode) and like to be able to treat rules as guidelines. The trouble is how can you scale this to millions of developers, and what are those limits of the human mind when more and more AI-generated code will be used?

I think the truth is that we just CAN'T scale that way with the current programming languages/models/paradigms. I can't PROVE that hypothesis, but it's not hard to find examples of big software projects with lots of protocols, conventions, failsafes, QA teams, etc, etc that are either still hugely difficult to contribute to (Linux kernel, web browsers, etc) or still have plenty of bugs (macOS is produced by the richest company on Earth and a few years ago the CALCULATOR app had a bug that made it give the wrong answers...).

I feel like our programming tools are pretty good for programming in the small, but I suspect we're still waiting for a breakthrough for being able to actually make complex software reliably. (And, no, I don't just mean yet another "framework" or another language that's just C with a fancier type system or novel memory management)

Just my navel gazing for the morning.

There’s also the effect that a certain code structure that’s clearer for a senior dev might be less clear for a junior dev and vice versa.

That's exactly what I try to do. I think it's an unpopular opinion though, because there are no strict rules that can be applied, unlike with pure ideologies. You have to go by feel and make continuous adjustments, and there's no way to know if you did the right thing or not, because not only do different human minds have different limits, but different challenges don't tax every human mind to the same proportional extent.

I get the impressions that programmers don't like ambiguity in general, let alone in things they have to confront in real life.

On a positive note, most AI-gen code will follow a style that is very "average" of everything it's seen. It will have its own preferred way of laying out the code that happens to look like how most people using that language (and sharing the code online publicly), use it.

My intro to programming was that I wanted to be a game developer in the 90s. Carmack and the others at Id were my literal heroes.

Back then, a lot of code optimizations was magic to me. I still just barely understand the famous inverse square root optimization in the Quake III Arena source code. But I wanted to be able to do what those guys were doing. I wanted to learn assembly and to be able to drop down to assembly and to know where and when that would help and why.

And I wasn't alone. This is because these optimizations are not obvious. There is a "mystique" to them. Which makes it cool. So virtually ALL young, aspiring game programmers wanted to learn how to do this crazy stuff.

What did the old timers tell us?

Stop. Don't. Learn how to write clean, readable, maintainable code FIRST and then learn how to profile your application in order to discover the major bottlenecks and then you can optimize appropriately in order of greatest impact descending.

If writing the easiest code to maintain and understand also meant writing the most performant code, then the concept of code optimization wouldn't even exist. The two are mutually exclusive, except in specific cases where it's not and then it's not even worth discussing because there is no conflict.

Carmack seems to acknowledge this in his email. He realizes that inlining functions needs to be done with careful judgment, and the rationale is both performance and bug mitigation. But that if inlining were adopted as a matter of course, a policy of "always inline first", the results would quickly be an unmaintainable, impossible to comprehend mess that would swing so far in the other direction that bugs become more prominent because you can't touch anything in isolation.

And that's the bane of software development: touch one thing and end up breaking a dozen other things that you didn't even think about because of interdependence.

So we've come up with design patterns and "best practices" that allow us to isolate our moving parts, but that has its own set of trade-offs which is what Carmack is discussing.

Being a 26 year veteran in the industry now (not making games btw), I think this is the type of topic that you need to be very experienced to be able to appreciate, let alone to be able to make the judgment calls to know when inlining is the better option and why.

> other times I'll spend days just breaking up thousand line functions into simpler blocks just to be able to follow what's going on

Absolutely, I'll break up a long block of code into several functions, even if there is nowhere else they will be called, just to make things easier to understand (and potentially easier to test). If a function or procedure does not fit on one screen, I will almost always break it up.

Obviously "one screen" is an approximation, not all screens/windows are the same size, but in practice for me this is about 20-30 lines.

That doesn't seem like holding two opposing thoughts. Why is balancing contradictory actions to optimize an outcome different to weighing pros and cons?

To make an advance in a field, you must simultaneously believe in what’s currently known as well as distrust that the paradigm is all true.

This gives you the right mindset to focus on advancing the field in a significant way.

Believing in the paradigm too much will lead to only incremental results, and not believing enough will not provide enough footholds for you to work on a problem productively.

> I was creating inconsistencies that younger developers nitpick

Obligatory: “A foolish consistency is the hobgoblin of little minds"

Continued because I'd never read the full passage: "... adored by little statesmen and philosophers and divines. With consistency a great soul has simply nothing to do. He may as well concern himself with his shadow on the wall. Speak what you think now in hard words, and to-morrow speak what to-morrow thinks in hard words again, though it contradict every thing you said to-day. — 'Ah, so you shall be sure to be misunderstood.' — Is it so bad, then, to be misunderstood? Pythagoras was misunderstood, and Socrates, and Jesus, and Luther, and Copernicus, and Galileo, and Newton, and every pure and wise spirit that ever took flesh. To be great is to be misunderstood.” ― Ralph Waldo Emerson, Self-Reliance: An Excerpt from Collected Essays, First Series

You are probably reaching for Hegel’s concept of dialectical reconciliation

What makes an apprentice successful is learning the rules of thumb and following them.

What makes a journeyman successful is sticking to the rules of thumb, unless directed by a master.

What makes a master successful is knowing why the rules of thumb exist, what their limits are, when to not follow them, and being able to make up new rules.

That maxim ("an intelligent person should be able to hold two opposing thoughts at the same time") is also used by religious groups to indoctrinate people. Be careful!

That’s undoubtedly a Zelda Fitzgerald quote (her husband plagiarized her shamelessly).

As a consequence of the Rule of Three, you are allowed to have rules that have one exception without having to rethink the law. All X are Y except for Z.

I sometimes call this the Rule of Two. Because it deserves more eyeballs than just being a subtext of another rule.

> My goal in most cases now is to optimize code for the limits of the human mind (my own in low-effort mode)

I think you would appreciate the philosophy of the Grug Brained Developer: https://grugbrain.dev

To a certain sort of person, conversation is a game of arriving at these antithesis statements:

   * Inlining code is the best form of breaking up code. 
   * Love is evil.
   * Rightwing populism is a return to leftwing politics. 
   * etc.

> limits of the human mind when more and more AI-generated code will be used

We already have a technology which scales infinitely with the human mind: abstraction and composition of those abstractions into other abstractions.

Until now, we’ve focused on getting AI to produce correct code. Now that this is beginning to be successful, I think a necessary next step for it to be useful is to ensure it produces well-abstracted and clean code (such that it scales infinitely)

Wait, isn't that just Doublethink from 1984? Holding two opposing thoughts is a sign that your mental model of the world is wrong and that it needs to be fixed. Where have you heard that maxim?

There is a longer version of this thought-provoking post, also including Carmack's thoughts in 02012, at https://cbarrete.com/carmack.html. But maybe that version has not also had threads about it.

You're over-crediting Carmack and under-crediting current game devs. 3-5 frames might be current end-to-end latency, but that's not what Carmack is talking about. He's just talking about the game loop latency. Even at ~4 frames of end-to-end latency, he'd be talking about an easily avoided 20% regression. That's still huge.

To be fair, back in 2014 that was one frame at 60Hz or slower for some titles. At 80-120Hz, 3-5 frames is comparatively similar time.

> In this era of 3-5 frame latency being the norm (at least on e.g. the Nintendo Switch)

Which titles is this true for? Have you or anyone else measured?

Is this kind of like 300 was a movie about a Frank Miller novel about a Greek legend about the actual Battle of Thermopylae?

Here's the link where he discusses functional programming style:

https://web.archive.org/web/20170116040923/http://gamasutra....

He does not say that that his email is completely outdated - he just says that calling pure functions is exempt from the inlining rule.

He's not off writing pure FP now. His approach is still deeply pragmatic. In the link above he discusses degrees of function purity. "Pure FP" has a whole different connotation - where whole programs are written in that constrained style.

I think more people grasp functional programming all the time, or at least the most salient detail: referential transparency. It’s easy to show the benefits in the small, without getting heavy on academics: pure functions are easier to test, understand, and change with confidence. All three of these reinforce each other, but they’re each independently beneficial as well.

There are tons of benefits to get from learning this lesson in a more intentional way—I know that I changed my entire outlook on programming after some time working in Clojure!—but I’ve seen other devs take the same lessons in multi-paradigm contexts as well.

> he's moved on from inlining and now does pure functional programming

Neither of those are true. He does more FP ”where reasonable“, and that decreases the need for inlining. He does not do pure FP, and he still inlines.

That most wont get it is due to the fact that most are kind of "industrial programmers", who only learn and use mainstream OOP languages amd as such never actually use a mainly FP language a lot. Maybe on HN the ratio is better than on the whole market though.

Some grasp it but see its trade-off contract, which is demanding.

I've never seen pure FP...

This is why I think it's a mistake that many popular languages, including standard c/c++, do not support nested function definitions. This for me is the happy medium where code can be broken into clear chunks, but cannot be called outside of the intended scope. A good compiler can also detect if the nested function is only called once and inline it.

Of course all this needs to be weighed against maintainability and readability of the code. If the code base is not mainly about something very performance critical and this kind of thing shows to be a bottleneck, then changing things away from more readable towards performance optimized implementation would require a very good justification. I doubt, that this kind of optimization is justified in most cases. For that reason I find the wording "prematurely breaking out code" to be misleading. In most cases one should probably prioritize readability and maintainability and if breaking code out helps those, then it cannot be premature. It could only be premature from a performance limited perspective, which might have not much to do with the use case/purpose of the code.

It is nice, if a performance optimization manages to keep the same degree of readability and maintainability. Those concerns covered, sure we should go ahead and make the performance optimization.

That's not an improvement, as it screws up the code flow. The point of inline blocks is that you can read the code the same way as it is executed. No surprised that code might be called twice or that a function call could be missed or reordered. Adding real functions causes exactly the indirection that one wanted to avoid in the first place. If the block has no name you know that it will only be executed right where it is written.

Not sure I believe the benefit of this approach outweighs the added difficulty wrt testing, but I certainly agree that Python needs a yikes keyword :-)

The latter pattern is very popular in Python web scraping and data parsing niches as the code is quite verbose and specific and I'm very happy with this approach. Easy to read and debug and the maintenance is naturally organized.

> Inlining functions also has the benefit of not making it possible to call the function from other places.

Congrats, you've got an untestable unit.

Funny enough, the equivalent of your Python example is how Haskell 'fakes' all functions with more than one argument (at least by default).

Imperative blocks of code in Haskell (do-notation) also work like this.

Where is the part, where this is "careful"? This is just how scopes work. I don't see what is special about the inner functions using things in the scope of the outer functions.

So inlining is the private of functions without a object. Pop it all to stack, add arguments, set functionpointer to instructionstart of inline code, challenge accepted, lets go to..

That’s gonna be quite expensive, don’t do this in hot loops. You’re re-defining and re-creating the function object each time the outer function is called.

You can do this in C++, too, but the syntax is a little uglier.

It might be a benefit in some cases, but I do feel that f1/f2/f3 are the prime candidates for actual unit testing

It's possible to nest subprograms within subprograms in Ada. I take advantage of this ability to break a large operation into one or more smaller simpler "core" operations, and then in the main body of the procedure write some setup code followed by calls to the core operation(s).

Remember to `nonlocal xs, db, logger` inside those inner functions. I'm not sure if this is needed for variables that are only read, but I wouldn't ever leave it out.

I find the inlined style can actually improve clarity.

A lot of code written toward the "uncle bob" style where you maximize the number of functions has fantastic local clarity, you can see exactly what the code you are looking at is doing; but atrocious global clarity, where it's nearly impossible to figure out what the system does on a larger scale.

Inlining can help with that, local clarity deteriorates a bit, but global clarity typically improves by reducing the number of indirections. The code does indeed also tend to get faster, as it's much easier to identify and remove redundant code when you have it all in front of you. ... but this also improves the clarity of the code!

You can of course go too far, in either direction, but my sense is that we're often leaning much too far toward short isolated functions now than is optimal.

And before that, 2D games (side-scrolling platformers were not a thing on PC hardware until Carmack did it, iirc). I think his main thing is balancing clarity - what happens when and in what order - with maintainability.

Compare this with enterprise software, which is orders of magnitude more complex than video games in terms of business logic (the complexity in video games is in performance optimization), but whose developers tend to add many layers of abstraction and indirection, so the core business process is obfuscated, or there's a billion non-functional side activities also being applied (logging, analytics, etc), again obfuscating the core functionality.

It's fun to go back to more elementary programming things, in e.g. Advent of Code challenges or indeed, game development.

I agree with this in general, but his essay on functional programming in C++ (linked at the top of the page) is phenomenal and is fantastic general advice when working in any non-functional language.

It’s called “self documenting code” and the way you self document code it is by taking all your comments and make them into functions, named after your would-be comment.

I’m not a fan either.

This can be done in a good way and in bad ways. With most code you will be calling builtin procedures/functions. You also don't look under the hood for those usually. But for the code of your coworker it seems to irritate you. This could mean many things. Just to name a few: (1) The names are not giving a good idea what those functions do. (2) The level of abstraction is not the same inside the calling function, so that you feel the need to check the implementation detail of those small functions. (3) You don't trust the implementation of those smaller functions. (4) The separated out functions could be not worth separating out and being given names, because what the code in them does is clear enough without them being separated out. (n) or some other reason.

The issue does not have to be that those things are split out into separate small functions. The issue might be something else.

Sometimes it's easier to define some vocabulary and then use it. Like defining push and pop on a stack vs stack[++ix] = blah and blah = stack[ix--].

And avoids needing to think about it being prefix or postfix after you don't that one time.

But at other times it's insufferable, when the abstraction is leaky and unintuitive.

> the one was application initialisation

...and then you want to parallelize as much as possible to allow for fast boot times which helps the development process immensely.

One of the things I've learned is that optimizing for developer quality of life is one of the best approaches when it comes to correctness and performance. Then, the developers would be able to run multiple iterations of the real thing.

Probably the more important link. He's basically saying his old email is outdated and he does pure FP now.

This is a heavily simplified version of what I'm suspecting he's trying to portray, key this wouldn't be useful for utility functions like string manipulation but more business logic being used across similar functions:

  def processOrder():
      # Some common processing logic
      print("Processing the order...")
  
  def placeOnlineOrder():
      processOrder()
      print("Sending confirmation email...")
  
  def placeInStoreOrder():
      processOrder()
      print("Printing receipt...")
  
  # Calls from different locations
  placeOnlineOrder()
  placeInStoreOrder()

  def processOrder(order_type):
      # Common processing logic
      print("Processing the order...")
  
      if order_type == "online":
          print("Sending confirmation email...")
      elif order_type == "in_store":
          print("Printing receipt...")
  
  # Unified calls with different flags
  processOrder("online")
  processOrder("in_store")

In C++ it's an idiom to use immediately invoked lambdas:

  auto x = []{
    /*...*/
    return 5;
  }();

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p28...

I'm not convinced that automatic checking of copy-paste errors of such blocks make much sense though. At least I think the false positive rate would be way too high.

Regarding compound statements returning values: There are a number of languages which have that, including Rust. Ironically, it made me wish for a reversed form of the construct, i.e. something like

    { ...; expr } --> x;
    // x is a new variable initialized to expr

Can you help me understand why this would be beneficial, other than avoiding using the word "function"?

It allows one backward branch. Think of it like hand-rolling your OS scheduler for processes/threads. You also have to track your "program counter" yourself. As a silly example:

  typedef enum state {EVEN, ODD} state_t;
  state_t task1 = EVEN;
  state_t task2 = EVEN;
  while (1) {
    switch(task1) {
    case EVEN:
        // do even things
        task1 = ODD;
        break;
    case ODD:
        // do odd things
        task1 = EVEN;
        break;
    default:
        fprintf(stderr, "WTF?\n");
        exit(1);
    }
    switch(task2) {
    case EVEN:
        // do even things
        task2 = ODD;
        break;
    case ODD:
        // do odd things
        task2 = EVEN;
        break;
    default:
        fprintf(stderr, "WTF?\n");
        exit(1);
    }
  }

You can do a lot with a program that looks like:

  while(1) {
    if (condition1)
      ...
    if (condition2)
      ...
    // etc
  }

One advantage is that the program will never get into an unbounded loop because the program counter will always advance towards the end of the main loop.

Well, you have one backward branch at the end of the program, and you inline your subroutines. I'm pretty sure you've written shaders for ancient GPUs that had similar limitations? And anything you can do in hardware you can do without subroutine calls, and in hardware the loop starts again on every clock cycle.

First discussed here back then: https://news.ycombinator.com/item?id=8374345

2007

That honestly feels like a minor problem, and not something to optimize for. Also an aggressively inlining compiler will experience exactly the same problem. AFAIK at least clang always inlines a static (as in internal linkage) function if it's used only once in the translation unit, no matter how large it is.

If you are willing to make code worse to micro optimize compile times (not even sure this is true) then you should not use any modern language with complex type checking (rust, swift, C#, etc).

None.

> The real enemy addressed by inlining is unexpected dependency and mutation of state, which functional programming solves more directly and completely. However, if you are going to make a lot of state changes, having them all happen inline does have advantages; you should be made constantly aware of the full horror of what you are doing. When it gets to be too much to take, figure out how to factor blocks out into pure functions (and don.t let them slide back into impurity!).

Some years ago at job foo I wrote a Ruby library that was doing some stuff. Time was of the essence, I was a one-man team, and the trickiness of it required a clear understanding of the details, so I wrote a single ~1000 LOC file comprising of the entirety of the namespace module of that library, with but a couple or three functions.

Then a new hire joined my one-man team. I said: apologies for this unholy mess, it's overdue for a refactoring, with a bunch of proper classes with small methods and split in a few files accordingly. They said: not at all, the code was exceptionally clear; I could sit and understand every bit of it down to the grittier critical details in under an hour, and having seen it written this way it is obvious to me that these details of interactions would not have been abstracted away, but obscured away.

> Minimize control flow complexity and “area under ifs”, favoring consistent execution paths and times over “optimally” avoiding unnecessary work.

If your control loop must always run under 16ms, you better make sure the worst case is 16ms rather than trying to optimise best or mid case. Avoid ifs that skips processing, that's good for demo but doesn't help reaching prod quality goals. Sometimes it doesn't bring the benefits you think, sometimes it hides poorly optimised paths, sometimes it creates subtle bugs. Of course always use your own discernment...

That would be very different in a typical cloud app where the goal is to keep CPU, memory and network usage as low as possible, not much caring about having a constant response time on each REST endpoint.

All the code which is not in hot path may conform to any rules, and typically is designed according to something like SOLID, to make understanding and maintenance as simple as possible (and suitable to any average coder).

All the code which performance, memory cost, etc. is critical, should be adjusted to fit into required confine even if it will violate all other tenets. This often results in combination of opposite approaches - anything that does well.

Finally, one just profiles the code and fixes all most spending paths. This is what now any average programmer can do. What it canʼt do - and what Carmack has been doing for decades - is to predict such places and fixes them proactively at architectural level; and to find tricky solutions that average joe-the-programmer hasnʼt heard ever.

Mostly, all of it. People who are not writing that kind of loop probably should not do any of this. Optimize for code clarity, which may involve either inlining or extracting depending on the situation.

my CPU does that all of the time, it is speculative execution :-)

It's at least twenty new web frameworks, but maybe not so long in low-level stuff. You can probably rely on C99 being available now more than you could in 2014.

You can artificially create scope. I often write code like:

    Foo f = null;
    {
      ... stuff with variables
      f = barbaz;
    }

Why's that? Uncle Bob seems pretty clear that most of your code should be free of side effects, and that necessary state mutation should be isolated to one place. Carmack is saying the same thing.

It means not using explicit functions, just writing the same code as little inline blocks inside the main function because it allows you to see all the things that would be hidden if all the code wasn't immediately visible.

To the other point though, the quality of compiler inlining heuristics is a bit of a white lie. The compiler doesn't make optimal choices, but very few people care enough to notice the difference. V8 used a strategy of considering the entire source code function length (including comments) in inlining decisions for many years, despite the obvious drawbacks.

“Comment threat” is a nice one.

This isn't actually an FP post.