But all of those correctness are imaginary. The hardware only enforce a few (and it may be buggy). The OS adds some more (and it’s buggy). The compiler/interpreter may have bugs (but that’s rarely a nuisance) and the libraries are often brittle. There are cracks everywhere in the tower of abstractions.

The code has never mattered. What has always mattered is the knowledge of what is the model of correctness of the software (programming as a theory by NauR), so that you can discern where a program is wrong.

The thing is a crash or some other immediate errors are actually nice to have. You get to react immediately and can have a core dump or a stacktrace that points you the error. What is truly a terror is silent corruption (wrong order of operations, wrong values for a comparison that has expanded the idea of correctness, security issues that has been backdoored for years,…).

As Hoare said:

  There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.
  The first method is far more difficult.

Why does good code imply never shipping?

Managers and Developers have different thresholds for “good enough to release”. The former are not the one on call for bugs or the one that get blamed for outage, but they are the ones that get praised when projects are completed quickly. Anything that’s past demo level is good for them.

If you have a good architecture and keep good code hygiene, then velocity is easy. Without that, everything will slow to a crawl.

Product Managers coding is like Developers writing marketing pitches.

As for the AI code, the most defining elements are unneeded complexity and low understanding of the abstraction involved. When you need a 10 lines functions, the AI will happily write an entire module because that’s how a fully implemented domain is like. But it’s not part of the requirements. As for the low understanding, you will see strange code, which are not fully antipattern, but are definitely not needed as it solves issue that the platform/library/framework doesn’t have or already have a solution for.

YMMV, but I got all of these through words of mouth (and WhatsApp status updates). I think it’s ok to be estranged from a friend or a relative. The next time, we meet, I can ask them how everything is going and what has happened. And if they want they can show me pictures then.

It’s kinda the old saying about $900/hr expert that only taps with an hammer. The price is not about tapping, it’s about knowing where to tap.

Once you get familiar with it, it becomes an anticipation game. And you on the stand usually as a better view of a play than the players. So while there’s only passing going on, you start to sense the strategy shifts. And you may even think it’s either doomed or have a high chance of success, but the opposite happens.

A goal is the reward for high amount work, not a foregone conclusion. That’s what makes a penalty so painful.

UEFI could have supported something like ELF and do away with real mode. Intel and Amd could have just introduced a new line of cpu and everyone could have transitioned to that (with maybe shims to soften the change). But everyone is all about backwards compatibility and compile once, runs for eternity.

But AI proponents are more than happier to brandish carefully curated anecdotes than to do a systematic study of risks and impacts.

Yes, we’re not the one paying for Linux development, but its subsystems are so complicated for general purpose computing. Like fitting formula 1 car parts onto a camry.

While I’ve not bothered to profile it, but it seems that process that have lot of mapped pages is the issue (firefox, emacs,…). In the emacs case, the issue is when the main process trying to fork-exec, if I start a shell session (with shell-mode or term-mode), it works fine.