Yes, and it is the engineering experience/skill to know when to follow the "rules" of the reference architecture, and when you're better off breaking them, that's the entire thing that makes someone a senior engineer/manager/architect whatever your company calls it.

Your newest team member sounds like someone worth holding onto.

I think the only way this gets better is with software development tools that make it impossible to create invalid states.

In the physical world, when we build something complex like a car engine, a microprocessor, or bookcase, the laws of physics guide us and help prevent invalid states. Not all of them -- an upside down bookcase still works -- but a lot of them.

Of course, part of the problem is that when we build the software equivalent of an upside down bookcase, we 'patch' it by creating trim and shims to make it look better and more structurally sound instead of tossing it and making another one the right way.

But mostly, we write software in a way that allows for a ton of incorrect states. As a trivial example, expressing a person's age as an 'int', allowing for negative numbers. As a more complicated example, allowing for setting a coupon's redemption date when it has not yet been clipped.

I don't think we will ever get the breakthrough you are looking for. Things like design patterns and abstractions are our attempt at this. Eventually you need to trust that however wrote the other code you have to deal with is sane. This assumption is false (and it might be you who is insane thinking they could/would make it work they way you think it does).

We will never get rid of the need for QA. Automated tests are great, I believe in them (Note that I didn't say unit tests or integration tests). Formal proofs appear great (I have never figured out how to prove my code), but as Knuth said "Beware of bugs in the above code; I have only proved it correct, not tried it". There are many ways code can be meet the spec and yet wrong because in the real world you rarely understand the problem well enough to write a correct spec in the first place. QA should understand the problem well enough to say "this isn't what I expected to happen."

I suppose that depends on the language and the elegance of your programming paradigm. This is where primitive simplicity becomes important, because when your foundation is composed of very few things that are not dependent upon each other you can scale almost indefinitely in every direction.

Imagine you are limited to only a few ingredients in programming: statements, expressions, functions, objects, arrays, and operators that are not overloaded. That list does not contain classes, inheritance, declarative helpers, or a bunch of other things. With a list of ingredients so small no internal structure or paradigm is imposed on you, so you are free to create any design decisions that you want. Those creative decisions about the organization of things is how you dictate the scale of it all.

Most people, though, cannot operate like that. They claim to want the freedom of infinite scale, but they just need a little help. With more help supplied by the language, framework, whatever the less freedom you have to make your own decisions. Eventually there is so much help that all you do as a programmer is contend with that helpful goodness without any chance to scale things in any direction.

> protocols, conventions, failsafes, QA teams, etc, etc that are either still hugely difficult to contribute to (Linux kernel, web browsers, etc)

To be fair here, I don't think it's reasonable to expect that once you have "software development skills" it automatically gives you the ability to fix any code out there. The Linux Kernel and web browsers are not hard to contribute to because of conventions, they're hard because most of that code requires a lot of outside knowledge of things like hardware or HTML spec, etc.

The actual submitting part isn't the easiest, but it's well documented if you go looking, I'm pretty sure most people could handle it if they really had a fix they wanted to submit.

> 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)

Readability is for human optimization for self or for other people's posterity and code comprehension to the readers mind. We need a new way to visualize/comprehension code that doesn't involve heavy reading and the read's personal capabilities of syntax parsing/comprehension.

This is something we will likely never be able to get right with our current man machine interfaces; keyboard, mouse/touch, video and audio.

Just a thought. As always I reserve the right to be wrong.

calculator app on latest macos (sequoia) has a bug today - if you write FF_16 AND FF_16 in the programmer mode and press =, it'll display the correct result - FF_16, but the history view displays 0_16 AND FF_16 for some reason.

> 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...

This is stated as if surprising, presumably because we think of a calculator app as a simple thing, but it probably shouldn't be that surprising--surely the calculator app isn't used that often, and so doesn't get much in-the-field testing. Maybe you've occasionally used the calculator in Spotlight, but have you ever opened the app? I don't think I have in 20 years.

We've been there, done that. CRUD apps on mainframes and minis had incredibly powerful and productive languages and frameworks (Quick, Quiz, QTP: you're remembered and missed.) Problem is, they were TUI (terminal UI), isolated, and extremely focused; i.e. limited. They functioned, but would be like straight-jackets to modern users.

(Speaking of... has anyone done a 80x24 TUI client for HN? That would be interesting to play with.)

> is a way to transmit concepts from one humans head to another (just like writing)

That's almost its primary purpose in my opinion... the CPU does not care about Ruby vs Python vs Rust, it's just executing some binary code instructions. The code is so that other people can change and extend what the system is doing over time and share that with others.

I think a lot of the traditional teachings of "rhetoric" can apply to coding very naturally—there's often practically unlimited ways to communicate the same semantics precisely, but how you lay the code out and frame it can make the human struggle to read it straightforward to overcome (or near-impossible, if you look at obfuscation).

Computational thinking is more important than software per se.

Computational thinking is the mathematical thinking.

Or rather, senior devs have learned to care more for having clear code rather than (over-)applying principles like DRY, separation of concerns etc., while juniors haven't (yet)...

I bumped into that issue, and it caused a lot of friction between me and 3 young developers I had to manage.

Ideas on how to overcome that?

> there are no strict rules that can be applied

The rules are there for a reason. The tricky part is making sure you’re applying them for that reason.

What I meant to say was that when people encounter contradictory statements like "always inline one-time functions" and "breakdown functions into easy to understand blocks", they try to only pick one single rule, even if they consider the pros and cons of each rule.

After a while they consider both rules as useful, and will move to a more granular case-by-base analysis. Some people get stuck at rule-based thinking though, and they'll even accuse you of being inconsistent if you try to do case-by-case analysis.

Not sure, didn't Hegel say that there should be a synthesis step at some point? My view is that there should never be a synthesis when using these principles as tools, as both conflicting principles need to always maintain opposites.

So, more like Heraclitus's union of opposites maybe if you really want to label it?

No you've got it completely backwards. Reality has multiple facets (different statements, all of which can be true) and a mental model that insists on a singular judgement is reductionist, missing the forest for the trees. Light is a wave and a particle. People are capable of good and bad. The modern world is both amazing and unsustainable. etc.

Holding multiple truths is a sign that you understand the problem. Insisting on a singular judgement is a sign that you're just parroting catchy phrases as a short cut to thinking; the real world is rarely so cut and dry.

It's not referring to cognitive dissonance.

The original article literally starts with this:

> In the years since I wrote this, I have gotten much more bullish about pure functional programming, even in C/C++ where reasonable: (link) > >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.

He explicitly says that functional programming solves the same issue as inlining but more directly and completely.

Thank you for this. I appreciate that this (classic) article lays bare the essence of FP without the usual pomp and "use Lisp/Scheme/Haskell already" rhetoric. My takeaway is that FP is mostly about using functions w/o side effects (pure), which can be achieved in any programming language provided you're diligent about it.

He literally said he’s bullish on pure fp. Which means he is off writing pure fp. His own article about it never explicitly or implicitly implies a “pragmatic approach”.

I never said he said his email was completely outdated. He for sure implies it’s outdated and updates us on his views of inlining which I also mentioned.

"pure FP" does not mean only writing in a functional style. Purity refers to referential transparency, ie., functions do not depend on or modify some global state.

He literally says he’s more bullish on pure fp. Read it. And I also wrote about where he still inlines.

Not just this. Modularity is the main insight as well. The reason why oop doesn’t work is because methods can’t be broken down. Your atom is oop is literally a collection of methods tied to mutating state. You cannot break down that collection further.

In pure fp. You can break your function down into the smallest computational unit possible. This is what prevents technical debt of the architectural nature as you can rewrite your code as simply recomposing your modular logic.

You do want to draw a strict line. When I say most programmers don’t get it… I’m talking about you. You don’t get why carmack is bullish about pure fp. You think it’s just map, reduce and filter and you don’t get why those functions are irrelevant.

To you you’re just fulfilling an ocd need to simplify your code and make it more pretty. There is deeper insight here that you missed and even when you read what carmack wrote about pure fp I doubt you’ll internalize the point.

Lisp is not pure. That’s why you don’t have the insight. For the true insight you need to learn about Haskell in a non trivial way. Not just youtube videos, but books that teach you the language from first principles. You need to understand the IO monad. And why it makes Haskell pure and how it forces you to organize your code in a completely different way. This is not an easy thing to understand.

The IO monad, when it appears, infects your code with the IO type and makes it extremely annoying to get rid of. I had a friend who learned Haskell and hated Haskell because of the IO monad. He stopped learning haskell to early and he never "got it".

If you reach this point you have to keep learning about Haskell until you understand why things are the way they are with haskell.

Just remember this: the annoyance of the IO monad is designed like that so that you write your logic in a way that doesn’t allow the monad to pollute most of your code.

With practice it just becomes another paradigm of programming. The trade off is really a skill issue from this perspective.

The larger issue is performance which is a legitimate reason for not using fp in many cases. But additionally in many cases there is no performance trade off.

It’s communication to programmers who do get it.

I love to teach and explain but this is one of those things that can’t be conveyed. You have to do it yourself.

If you want an explanation though, use Google. But I don’t think explanations actually help you grok what’s really happening. You really have to come to catharsis yourself.

Learn Haskell. Learn it to the point where you completely understand the purpose of the IO monad and why it exists and helps a program organize better. Then you will understand.

When you do get it. You’ll be among a small few who have obtained something that’s almost like forbidden knowledge. No one will “get” you.

I would recommend you take a look at Haskell or Elm.

John Karmack did and talked about it https://m.youtube.com/watch?v=1PhArSujR_A

I might add Carmack's take on functional programming https://web.archive.org/web/20120501221535/http://gamasutra....

Surely if you’ve seen any non-trivial amount of code, you have seen pure FP applied piecemeal even if not broadly. A single referentially transparent function is pure FP, even if it’s ultimately called by the most grotesque stateful madness.

You need to learn Haskell in a non trivial way. Code in it. And then you need to completely internalize why the IO monad exists and why it encourages the programmer to code in ways that stay away from using it.

I had a friend (who’s in general a good programmer) learn Haskell and then get completely annoyed by the IO monad so that he quit learning Haskell. So yeah, it’s not easy to “get it” You only get it with reading and practice. Really you just need to completely internalize and grasp the purpose of the IO monad in Haskell.

I don't think high frame rates are common outside of PC gaming yet.

Wikipedia indicates the Switch maxes out at 1080p60, and the newest Zelda only at 900p30 even when docked

https://en.m.wikipedia.org/wiki/Nintendo_Switch

yeah but when people talk about input lag for consoles its generally still in the 60hz sense, rare for games to be 120hz

smash brothers ultimate for example runs at 60fps and has 5-6 frames of input lag

Why would you even bother running at a game at 120Hz if the user's response to what's being drawn is effectively 24-30 FPS?

I've heard that a good reaction time is around 200 ms, some experiments seem to confirm this figure [1]. At 60Hz, a frame is displayed every 17 ms.

So it would take a 12 frames animation and a trained gamer for a couple of frames to make a difference (e.g. push the right button before the animation ends and the opponent's action takes effect).

[1] https://humanbenchmark.com/tests/reactiontime/statistics

Almost every title. This is common knowledge.

Yeah that’s a valid point. I tend to have in mind that as soon as I pull any of the inner functions out to the publicly visible module level I can say goodbye to ever trying to stop people reusing the code when I don’t really want them to.

For example, if your function has an implicit, undocumented contract such as assuming the DB is only a few milliseconds away, but they then reuse the code for logging to DBs over the internet, then they find it’s slow and speed it up with caching. Now your DB writing code has to suffer their cache logic bugs when it didn’t have to.

What is the benefit of such a yikes? Or do you consider it a yikes language as a whole?

Personally I like that functions can be inside functions, as a trade off between inlining and functional seperation in C++.

The scope reduction makes it easier to track bugs while it has the benefits of separation of concern.

Congratulations, you are writing test for things that would not need test if weren't put behind a under-defined interface. Meanwhile sprint goals are not met and overall product quality is embarrassing, but you have 100% MC/DC coverage of your addNumbersOrThrowIfAbove(a, b, c).

Which is usually a positive. Testing tiny subunits usually just makes refactoring and adding new features hard while not improving test quality.

Ideally, you've just moved the unit boundary to where it logically should be instead of many small implementation details that should not be exposed.

The unit here is the email, not the email's link or subjects. Those are implementation details.

This is a major insight. Defining a local function isn't a big deal you can always just copy and pasta it out to global scope.

Any time you merge state with function you can no longer move the function. This is the same problem as OOP. Closures can't be modular the same way methods in objects can't be modular.

The smallest unit of testable module is the combinator. John Carmack literally mentioned he does pure functional programming now which basically everyone in this entire thread is completely ignoring.

Yup, and I should have called this out as a downside. Thank you for raising it.

On visibility, one of the patterns I’ve always liked in Java is using package level visibility to limit functions to that code’s package and that packages tests, where they are in the same package (but possibly defined elsewhere.)

(This doesn’t help though with the reduction in argument verbosity, of course.)

Good point. I measured it for 10^6 loops:

(1) 40ms for inline code;

(2) 150ms for an inner function with one expression;

(3) 200ms for a slightly more complex inner function; and

(4) 4000ms+ for an inner function and an inner class.

  def f1(n: int) -> int:
      return n * 2

  def f2(n: int) -> int:
      def g():
          return n * 2
  
      return g()
  
  def f3(n: int) -> int:
      def g():
          for _ in range(0):
              try:
                  pass
              except Exception as exc:
                  if isinstance(exc, 1):
                      pass
                  else:
                      while True:
                          pass
                  raise Exception()
          return n * 2
  
      return g()
  
  def f4(n: int) -> int:
      class X:
          def __init__(self, a, b, c):
              pass
  
          def _(self) -> float:
              return 1.23
  
      def g():
          for _ in range(0):
              try:
                  pass
              except Exception as exc:
                  if isinstance(exc, 1):
                      pass
                  else:
                      while True:
                          pass
                  raise Exception()
          return n * 2
  
      return g()

Excessive use of external bindings in a closure can make it hard to reason about lifetimes in cases where that matters (e.g. when you find out that a huge object graph is alive solely because some callback somewhere is a lambda that closed over one of the objects in said graph).

> I'm not sure if this is needed for variables that are only read

It’s not needed. In fact, you should leave it out for read-only variables. That’s standard practice - if you use `nonlocal` people reading the code will expect to see writes to the variables.

Not that bad?

    int main() {
        int a = -1;
        [&] {
            a = 42;
            printf("I'm an uncallable inline block");
        }();

        printf(" ");

        [&] {
            printf("of code\n");
        }();

        [&] {
            printf("Passing state: %d\n", a);
        }();

        return 0;
    }

C++ has lambdas and local classes. Local classes have some annoying arbitrary limitations, but they are otherwise useful.

In Java, a local function reference (defined inside a method and never used outside of this method ) is possible. Notre that this function is not really tied to an object, which is why I don't call it a method, and I don't use the expression "method reference", it is just tired to the function that contains it, which may be a method - or not.

Code can always be called outside of that scope just by returning function pointers or closures. The point is not to restrict calling that code, but to restrict the ability to refer to that piece of code by name.

As mentioned by others, C++ has lambdas. Even if you don't use lambdas, people used to achieve the same effect by using plenty of private functions inside classes, even though the class might have zero variables and simply holds functions. In even older C code, people are used to making one separate .c file for each public function and then define plenty of static functions within each file.

What I'm advocating here is only coincidentally a performance optimization. Readability and maintainability (and improved abstraction) are the primary concern and benefit of (sometimes) keeping things inline or more specifically of reducing entropy.

It doesn't seem to have, since https://news.ycombinator.com/from?site=cbarrete.com is empty.

Should we change the top link to that URL?

One thing that's nice about functions is that they force the associated block of code to be named, and for state that is specific to the function to be clearly separate from external state (closures aside). It would be good to be able to retain those advantages even in linear code that nevertheless has clear boundaries between different parts of it that would be nice to enforce or at least highlight, but without losing the readability of sequential execution.

To some extent you can have that in languages that let you create a named lambda with explicit captures and immediately invoke it, e.g. in C++:

   int g;

   void doThisAndThat(int a, int b, int c) {

      doThis: auto x = [&a, &b] {
        ...
      }();

      doThat: [&g, &c, &x] {
        ...
      }();
   }

The syntax makes it kind of an eyesore though. Would be nice to have something specifically designed for this purpose.

> atrocious global clarity

much like microservices.

"compare this with enterprise software, which is orders of magnitude more complex than video games in terms of business logic" Maybe this was true 20 years ago, but I do not think this is true today. Game code of some games is almost as complex as enterprise software or even more complex in some cases (think of grand strategy games like Civilization or Paradox games). The difference is that it still needs to be performant, so the evolutionary force just kills programmers and companies creating unperformant abstractions. In my opinion game programming is just harder than enterprise programming if we speak about complex games. (I have done both). The only thing which is easier in game programming is that it is a bit easier to see clearly in terms of 'business requirements', and also it is more meritocratic (you can start a game company anywhere on the globe, no need to be at business centers.) And of course game programming is more fun, so programmers do the harder job even for less money.

For people who think game programming is less complex than enterprise software, I suggest the CharacterMovementComponent class in unreal engine which is the logic of movement of characters (people) in a networked game environment... With multiple thousand lines of code in just the header is not uncommon in unreal. And this is not complex because of optimization mostly. This is very complex and messy logic. Of course we can argue that networking and physics could be done in a simple naive way, which would be unacceptable in terms of latency and throughput, so all in all complexity is because of optimization after all. But it is not the 'fun' elegant kind of optimization, it is close to messy enterprise software in some sense in my opinion.

>Compare this with enterprise software, which is orders of magnitude more complex than video games in terms of business logic

I dont buy it in games like gta, cyberpunk or witcher 3

> 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.

Smooth side-scrollers did exist on the PC before Keen (An early one would be the PC port of Defender). Moon Patrol even had jumping in the early '80s.

Furthermore other contemporaries of Carmack were making full-fledged side-scrolling platformers in ways different from how Keen did it (there were many platformers released in 1990). They all involved various limitations on level design (as did what Keen used), but I don't believe any of them allowed both X and Y scrolling like the Keen games did.

Link at the top of the page broken, found an archived version at https://web.archive.org/web/20120501221535/http://gamasutra....