[this is an unfinished post! I may never finish it, or may substantially rewrite, add-to, or split up parts of it; some sentences trail off, and it has no ending]

It is well recognized that code can age poorly, but like many things, code can also age well. Like a fine cheese or wine, code can get better when left unattended.

In particular, I want to talk about how code "ages efficient" - as optimizations improve, and your language or system gets those optimizations implemented, your code will sometimes get more efficient for free.

But! Just like aging grapes need the right preparation to turn into wine instead of rotting slush, your code needs to be written in the right ways to be amenable to optimizations, instead of resisting and defeating optimizations.

Remember the XOR swap? For a brief moment in history, it was a more efficient way to swap variable values than using a temporary variable, because a compiler with no or minimal optimizations would just save that temporary variable on the stack. Then one day, compilers learned to keep a map in memory between registers used by the machine code and variables used by the source code - this was very simple, and had huge sweeping efficiency benefits across almost all code, because the compiler no longer had to keep moving stuff between the stack and registers for every single operation. And just like that, with no deliberate optimization of that specific special case, variable swaps through a temporary variables became free no-ops. Meanwhile the XOR swap remained three XOR operations, because it is much harder, and far less universally valuable, to write analysis that can symbolically simulate several operations on all possible inputs and notice when they cancel each other out, what effects they may have, and what other operations have the same effects but are more efficient.

We see this pattern repeat across software history.

Manual loop unrolling was more efficient once, but a good compiler or JIT optimizing VM can unroll your loops for you, and unlike you manually tweaking the source, the automatic optimization is in a better position where to choose the unrolling that best for the current target hardware.

Duff's Device was more efficient once, but it's easier and more broadly useful to have algorithms that can turn a clear simple loop into one of several options including a Duff's Device, than to have algorithms that can reverse-engineer the clear simpler loop from a Duff's Device.

And so on.

The thing is, it comes down to just one simple principle: write easy-to-analyze code:

Write code that sieves out and collapses possibilities as soon as possible. The sooner you error out on bad data or programmer error, the more of the code paths after can be transformed in ways that are more efficient but only produce the same result for the correct inputs.

Write code that maximizes locality of behavior and correctness.

Write code that most clearly and directly expresses your big-picture intended result. The more the intended result has to be inferred from the code, the harder it is

Write code that says what you mean in the semantics of that programming language,

Conveniently, you have a human brain, which is very limited in terms of working memory and speed, so when rigorously stepping through code, you can literally feel when code is harder or easier to analyze based on how much effort it takes to keep track of the full possibility space of what could happen at each operation.

That way for example canonical source code can look like `curl ... | sed 's/foo/bar/'` and the binary might use something like libcurl (ideally in a static includes way, although I suspect the world will keep insisting on the less efficient-to-implement approach of link-time optimization) and an inlined implementation of just the string-replacing logic of sed.

The unfortunate thing is that a realistic implementation would need a dictionary of heuristics and definitions - for a program with this name, parse the arguments like so, and based on that pick a pre-written implementation of it, and inline it. So if you have a non-standard or uncommon program, or are using a program in a very unusual or unexpected way, you might need to add/enhance/override the detection heuristics or program definition.

For example, any time a loop gets "optimized" in a way that changes whether or not it is infinite or terminates. Or a check gets removed. My first reaction is "what the hell? you just don't do that! if the author put a check here, maybe - wild concept, but hear me out - maybe it was for a good reason, so don't remove it!"

But then there are other times when I look at the actual logic that got optimized out, and my sympathy dies on the spot. For example:

for(int i = 0; i >= 0; i++) //try it a bunch of times

Now, I still have sympathy in the sense that I empathize and relate - I can imagine what it is like to get so used to thinking in terms of low level machine operations that this is how you naturally think to express it. I've been there. And if you get used to relying on that, it sucks to have the compiler screw you over by violating your knowledge like that, especially when that knowledge is correct for your target hardware. And it's horrifying when you realize that this could be code for an embedded controller in a medical device or power reactor, which relies on that loop terminating after all the tries to not kill people. I sympathize when it comes to the consequences, and the desire to attribute some fault to the compiler "optimizing" that out.

But I'm no longer sympathetic in the sense that I start to think "this was never the code you ought to have written in this case, even independent of undefined behavior, so you 'started it', you committed the first wrong without which this would never have happened". You know what would be more readable and intuitive to a human reader? More clear and direct? What would take less mental steps and knowledge for the human reader to think through? This:

for(int i = 0; i < INT_MAX; i++)

Where `INT_MAX` is from the standard `limits.h` header, or you can define your own if you're on a weird minimal embedded platform. (I would also rename `i` to `tries`, at which point the line comment is redundant since the code itself tells the reader all of the same information.)

Why is this better besides being well-defined, which is just a happy coincidence? Because the code logic is closer to directly expressing the actual behavior and intent. The intent is "iterate a lot of times" and the behavior is "iterate from zero until we reach the highest positive value the counter can express". The second variant explicitly directly just says that.

The first variant doesn't say that: it says "count up from zero for as long as the result is zero or higher". Now I'm all for being conscious of what kind of arithmetic you're doing, but in the first and most common one that humans are taught and usually think in, the above sentence implies an infinite loop. And I'm all for saying "if you're coding in C you should be better at thinking in wraparound arithmetic", but what I'm saying is that wraparound arithmetic is inherently more complex as a concept: when interpreting the code you can't just have the invariant that n+1 always produces a number one larger than n, you have to maintain the possibility that sometimes n+1 does something else. And even if we treat just having that in the mind as free, the reader still has to do extra mental steps to actually apply it:

the termination condition is when the counter becomes less than zero

can this become less than zero?

yes, if it wraps around (assuming that's what happens on this hardware, which I guess I'll have to just trust that it does because the code seems to intend to use that behavior)

which will be when?

right after the counter reaches the maximum integer value that an `int` can hold.

So your readers have to bring in more knowledge and do more mental steps just to reach "oh we're basically doing `INT_MAX` tries". Or you could just say that with your code. Because if you just say `i < INT_MAX`, then your mental steps are just:

the termination condition is when the counter reaches the maximum integer value that an `int` can hold.

I wish someone somehow enlightened me to this early on in my education as a programmer:

Code is human communication first, something that is executed second. Write your code for humans to read and understand and learn from, not for machines to interpret, compile, or execute.

Do not sacrifice anything in the code that benefits human understanding or reasoning about the code to benefit mindless execution of it unless you have good evidence that you must.

Code should be explanation - of intent, of assumptions, of expectations, of reasons and reasoning, of what possibilities were considered, and of what edge cases are accounted for.

Code should embody that explanation explicitly - if it was relevant in your head when you decided to write it that way, the code should try to express it.

After coding for the human, our next priority should be coding for the optimizer. The desire to write the most optimized code is good, but the best way to do that is by writing the most optimizable code.

The easier and simpler it is to analyze code - to prove what can or can't happen, what inputs can have what values, which values depend on each other, when resources are last used, and so on - the lower the bar for turning it into the most efficient form for any given targets and use patterns.

Hand-optimizing code usually destroys or severely obfuscates exactly that information, and often is only more optimal given additional assumptions that are invisible in the code and become false as the underlying hardware and software improves.

shouldn’t that be _source_PATH="$PATH" (added doublequotes) etc?

The first order approximation answer is "yes, good!"

The pedantic technical answer is:

Regular variable assignment is one of the two special places in the syntax of Bourne-like shells where field splitting and globbing are not done on the result of expansions, so it is always safe to leave them unquoted.

Caveat: I said regular variable assignment. That does not apply to assignments that are syntactically just arguments to other commands, like `export` or `env`.

Caveat to the caveat: `local` is special and has all sorts of other portability caveats - in at least some shells, assignments that are "arguments" to the `local` "command" are also syntactically special and bypass field splitting and globbing.