The evolution disagrees.
All major trophic level breakthroughs are powered by evolving a reserve of efficiency in which mult-step searching can occur.
multicellular life, collaboration between species, mutualism, social behavior, communication, society, civilization, language and cognition are all breakthroughs that permitted new feature spaces of exploration that required non-locally-optimal transitions by the involved systems FIRST to enable them.
Trust is expensive and can only get bought in the presence of a surplus of utility vs requirements.
Basically, intelligent behavior is optimizing for "future asymptotic entropy" vs maximizing any immediate value. How intelligent a system is then become a measure of how far in the future it can model and optimize entropy effectively for.
(updated with pdf link)
[1]: Thermodynamic Game Theory: https://adamilab.msu.edu/wp-content/uploads/AdamiHintze2018....
[2]: piKL - KL-regularized RL: https://arxiv.org/abs/2112.07544
[3]: Soft-Actor Critic - Entropy-regularized RL: https://arxiv.org/abs/1801.01290
[4]: "Soft" (Boltzmann) Q-learning = Entropy-regularized policy gradients: https://arxiv.org/abs/1704.06440
But your comment was refreshing, could you briefly expand on the "multicellular" life part? Did you mean that it enabled more non-locally-optimal transitions, or that it required them to appear?
Takes a lot of luck to evolve cooperation multiple times at once, much more likely to happen in a situation where the selection pressure is lower, not higher.
The thing about evolution is that you are sampling many times in different directions. So "luck" isn't that hard to achieve.
> Pretty sure those non-cooperative strategies quickly burn themselves to extinction though.
Um, most life hanging out in the same tropic level or lower is heavily predated upon. Competition is the norm.
Luck is hard for cooperation because it is a coordination problem. You basically have to evolve cooperation entirely as a unexpressed trait then trigger it in the population almost simultaneously. The mechanisms of cell cooperation are critical dividers on our evolutionary trees for a reason, they are rare and dramatic in consequence. Cell populations regressing in terms of coordination behavior (see cancer) is one of their most problematic failure modes and it is only very weakly selected against.
I'm referring to the predator-prey population cycles. If you overexploit your prey you are going to run out of food and see your population thin out rapidly from starvation. Hence hyper-competitive strategies would get outbreeded by less competitive but sustainable strategies.
High predation levels would require equally high cooperation levels amongst prey to ensure rapid reproduction to sustain the food supply. If we go down the food chain it's the same thing, plant life, celluar life, etc, has to be flourishing to sustain the upper levels.
> Take chances, make mistakes, and get messy.
But then seemed to indicate evolution disagrees.
I might be misunderstanding your point, but it sure seems like, evolution tries a bunch of stuff, and whatever reproduces kinda wins.
That seems like, take chances, make mistakes, get messy. That seems like the core of evolution.
Could you clarify or refine what you’re saying? The two seem at odds.
I got inspired by this article: https://writings.stephenwolfram.com/2024/05/why-does-biologi...
I used to do an "optimization" on my genetic algorithms. I'd ensure the highest scoring genome of the last population was a member of the new one. It made sure every single generation improved or stood still.
It was a good idea to keep a copy of the "best" genome around for final output, but by keeping it in the search space, I was damaging the ability of the algorithm to do it's job by dragging the search space constantly back to the most recent local optima.
> The evolution disagrees.
It’s not an either/or. Vast modularized localized improvement allows for the ability to prune and select what does and doesn’t work.
My point was there's no pressure without constraints. A faster-reproducing species will only apply a pressure if starts exhausting a resource or similar.
Ah yes monotonic-only improvement by way of making every small, messy mistake possible and still probably going extinct is definitely the way to go
Better for developers? Better for users?
Better for speed? Better for maintenance? Better license? Better software stack? Better telemetry? Better revenues through subscriptions?
> The key question for the designer is, “What would the system’s structure need to be so that <some feature> would be no harder to implement than necessary?” (It’s a bit surprising when designers don’t ask this question, instead simply asking, “What should the design look like?”—for what purpose?)
During my career, I have been in many situations where the SW architects tried to answer the second question: as if the architectural cleanliness was the goal unto itself. Software design patterns were misused, unneeded abstractions abounded everywhere, class hierarchies were created 15+ levels deep. There it was often brought up which is better and nicer and cleaner because the metric was aestetics.
Most of those arguments, however, are quickly brought to a stop, if we are actually asking the first question: how hard is it to add these new features? That said, I was frequently unable to convince coworkers in my past employments, that aestetics of the design is not the goal. They simply clung to it, to somewhat religious extent, identifying themselves with their "artwork".
But in the end there is never a clear answer. I am happy when people can explain what the positives and also the drawbacks of a design are. Pointing at “best practice” without explaining pros and cons is usually a big red flag.
They just encourage constructing monstrosities of a different kind. I don't think people who do stupid things in one paradigm will do any better in another paradigm. I see that a lot in the microservice vs monolith debate. If you can't manage a monolith you will also screw up microservices.
The worst thing is how hard it is to talk about it because all the books - by authors making more money from talking about software than from writing and maintaining code - recommend it, and it's just so SOLID and Hexagonal and looks obviously intuitively correct.
The sentence for preferring "composition over inheritance" for code reuse is in the book by the gang of four (the design patterns book). I really don't understand how we ended up in the situation, where 30 years old advice is still valid and still not followed. I lay, perhaps too much, blame on Java, which seems to have this baked into its infrastructure, but similar approaches have also been adopted in C++ with multiple inheritance making things even worse.
I mean, SOLID, when used appropriately, is also valid. The problem is that the design patterns are used where a simpler solution would work just as well.
They think their huge class diagrams and statically unverifiable mess of many structurally identical classes (in Typescript) is an example of DRY, composition, separation of concerns, inversion of control and encapsulation - all the great advice neatly packed into 50 files opaquely interconnected through dependency injection containers, where a simple 100 line function would have done the job and wouldn't cause a major headache for the poor guy who has to fix a bug in 3 years.
The root issue is that these guys never were the poor guy who has to fix a bug after 3 years. They moved on after a year or two of "implementing best practice approaches" to the next job.
This sounds good, but in my direct experience it is really really hard.
For example, sometimes you have a feature that is really easy to add. Just add a new argument or keyword or command and implement it in the guts.
But every once in a while you get a beautiful architecture that has a "direction" to it. And a horrendous requirement comes along and breaks everything. For example, port it to macos. Or add and call this third-party library. Or break it up into an SDK, a CLI and a web service.
sigh. guess that's why this kind of career keeps you on your feet.
People are vaguely good and competent, they leave systems in a locally-optimal state.
In general only changes that are "one step" are considered, and they allways leave things worse when you are currently in a locally optimal state.
A multi-step solution will require a stop in a lower-energy state on the way to a better one.
Monotonic-only improvement is the path to getting trapped. Take chances, make mistakes, and get messy.