Complexity can easily be manufactured. Comparing it to something as fundamental as energy is pure bollocks.
Heres an amusing and simple example of manufactured complexity: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
Heres an amusing and simple example of manufactured complexity: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
That said, there's no denying that there's probably a lot of unnecessary complexity in most software.
Energy does have a conservation law. Entropy does not. Not does information, complexity etc.
I majored in phyiscs, I'm familiar with these terms.
Grand parent post made no indication they were talking about essential complexity when they made their bold assertion about how it's conserved like energy.
I'm also not aware of any formal or precise way of measuring "essential complexity". Not in the way we do for energy or entropy.
Look at the sorting algorithms: there's always going to be some minimum amount of complexity / algorithm code, to sort in n log n.
If anyone proved such a result, I'm sure they would be awarded a prize of some kind.
Bubblesort has inferior time complexity than Timsort, but is simpler. The bounds of the comparative sort problem doesn't tell us that either.
A lot of real-world CRUD code, for instance, does nothing of computational interest whatsoever, but it isn't simple, because it has to cope with real-world business-logic complexity. (And possibly a lot of complexity beyond the necessary complexity, due to poor design, changing goals slowly messing up the code, etc.)
> You can describe the complexity of "code understanding" as the computational complexity required to answer a question about it, say the time it takes to find it or the length of the proof
I don't follow. How are proofs relevant? A programmer having to wade through poorly-named functions and a lack of documentation, is not well modelled by computational complexity theory.
> You could even talk about the simplest sorting algorithm as the one with the shortest proof.
Who'd care? That bears little relation to either the complexity theoretic properties of the algorithm/problem, or to complexity in the informal sense.
How do you define simple or complex?
> How are proofs relevant?
They are one way of measuring how hard or easy it is to know something, and I define simple as easy to answer questions about, and complex as the opposite.
It's obvious that the time/space complexity of a program can stay fixed while you arbitrarily raise the programming complexity of a program by arbitrarily raising the number of branches that are rarely taken, an action that won't affect the asymptotic time complexity of a thing.
And sure, you can talk about the Kolmogorov complexity of a string of computer code, but the minimal string representation of that code is unlikely to be one that a programmer would describe as simple. Even minimizing the string that would behave as that of the original program is usually non-desirable.
https://en.wikipedia.org/wiki/Programming_complexity
https://en.wikipedia.org/wiki/Computational_complexity_theor...
Introduce enterprise into any system and complexity goes over the roof ASAP - suddenly its not only your machine but TEAM of people, history, dashboards with metrics, logs, automation, security etc...
This one isn't even approaching any of it except dev side and CI.