hburd

You can cache the glyphs in an atlas and avoid re-rendering each glyph every time. But this comes with its own complications and tradeoffs.

There is a name for this phenomenon, it is called Conway's Law: https://en.wikipedia.org/wiki/Conway%27s_law

More recent commentators have noted a corollary - for software projects with a long lifetime of code reuse, such as Microsoft Windows, the structure of the code mirrors not only the communication structure of the organization which created the most recent release, but also the communication structures of every previous team which worked on that code.

I agree with almost every one of your points. I think I oversimplified my original point for the sake of clarity.

If you are throwing out maintainable code for the sake of performance, it had better be because you know that it's your bottleneck, and that the performance increase is worthwhile in the first place. "Performance for performance sake" shouldn't exist anywhere outside of hobby projects.

I would argue that responsive user interfaces are really important to user experience. Not many people are complaining because everyone is used to unresponsive apps, but that doesn't mean users wouldn't appreciate a more responsive app.

I would also add that there isn't always a tradeoff between performance and maintainability. If you can adopt some performant coding patterns that don't sacrifice maintainability, then absolutely do that. I think Casey's example of "switch-based polymorphism" is one such pattern(and I think the fact that Rust took a similar route to polymorphism is a vote in favour of this pattern).

I don’t think the percentage of time waiting for input has anything to do with this. Outside of video games, the way most people will see performance problems is in the latency of their UI interactions. You press a button and want to see the result as fast as possible.

In other words, the user’s entire perception of your program’s performance falls into that 0.1%.

You can actually override the SDL version at runtime, even if it is statically linked, though they still suggest to link dynamically: https://github.com/libsdl-org/SDL/blob/main/docs/README-dyna...

You can avoid the .c file by building the .h and passing the compiler a -DIMPLEMENTATION option.

Software engineering is about solving real problems. The only time you need to write malleable software is when the problem needs a malleable solution.

Pushing for everyone to write malleable software sounds like telling people to forget about the particular problems that they are solving, and telling them to solve a general problem instead. Now you’re writing a complicated system for general use, rather than a simple solution for a well-defined problem. Your solution will now take longer to develop, be harder to understand and MUCH harder to test properly (way more use cases).

Obviously some problems need general solutions. But if every problem needed a general solution nobody would get anything done.

> These days, I think most users will lose more time and be more frustrated by poor UI design, accidental inputs, etc. than any performance characteristics of the software they use.

I’m willing to bet that a significant percentage of my accidental inputs are due to UI latency.

I actually think it's actively harmful to hide problems that can be otherwise fixed. If the CPU is too busy to keep filling the audio buffer, the solution is to increase the buffer size to put less stress on the scheduler. I recently reduced my buffer size in Ableton Live, but I knew I had to increase it because I could hear pops. If these pops were being covered up, I wouldn't have realized my buffer size was too small and I'd be unknowingly introducing subtle artifacts into every recording.

Is undefined behavior really that bad when it's not causing problems?

I think the album "Future Shock" by Herbie Hancock, while technically electro, is a good example of techno's roots in funk. https://www.youtube.com/watch?v=tFM9bbfF0P4