I've got an extensional definition but not an intensional one. That is, I can look at two programs that do the same thing and tell you which one is simple, but I'm not sure what all goes into it at what weight.

One thing is code execution paths for later debugging. All else equal, code is simpler if everything you need to figure out what something does is in one place. Basically, minimizing the distance you need to travel in order to get related information. Keep variables closer to where you use them, etc.

There's some programming language specific stuff. A for loop that does a mapping is more complicated than calling a map on the collection. More generally, a program is simpler if it uses more specific abstractions, rather than using a very general abstraction in a highly specified way.

Likely, there's more than I'm completely forgetting but will recognize as general principles that I use.

Excellent point - I've had disagreements with people who thought their code was beautifully simple while I thought it was an over-engineered mess.

Who was right?

[NB Obviously, I was right, but it would help if there was some objective measure of complexity to justify it ;-)]

Let's take a page from the Orange Book days. Simplicity means you can:

1. Clearly map the code/functions to the specs of what it does almost line by line.

2. The code is expressed in a way simple enough for one person to understand it and verify it by hand.

3. The code is expressed in a way simple enough for a machine to verify it should someone want to try.

4. Minimal to no global effects/state happening in the local code.

These principles tend to result in code that's correct and easy to modify. I say they're a start on some objective measure of simplicity. We could empirically [dis]prove them as well with tests of various coding styles on people and tooling.