4 ms·

I disagree with the part where you say "complex systems can be reduced to smaller and simpler ones where making a decision doesn't have to mean unleashing a cos

I disagree with the part where you say "complex systems can be reduced to smaller and simpler ones where making a decision doesn't have to mean unleashing a cosmic horror." That's the whole problem with reductionist thinking, which fails when analyzing a chaotic system or a complex system. The behavior of the whole is greater than the sum of the parts because of hidden interactions between the smaller parts of the system. There are too many variables to account for, and small variations in initial conditions rapidly became very divergent outcomes. I get the sense that you may not have studied chaotic systems or complex systems in any level of detail. It might be a worthwhile effort to learn more about those systems, because they are essentially a refutation of reductionist thinking. You may understand your codebase completely, but I assure you, if you released it to a large enough group of people, they could find errors and bugs in your code because they will try things that would never occur to you. I am reminded of a video where a programmer spent three years training an ai model to beat an "impossible track" in trackmania, where he finds out that chaos built into the deterministic physics engine behind the game made his pursuit much more difficult. https://www.youtube.com/watch?v=kojH8a7BW04 https://www.youtube.com/watch?v=kojH8a7BW04

Sakos 2y ago
> That's the whole problem with reductionist thinking, which fails when analyzing a chaotic system or a complex system. The behavior of the whole is greater than the sum of the parts because of hidden interactions between the smaller parts of the system. There are too many variables to account for, and small variations in initial conditions rapidly became very divergent outcomes. > I get the sense that you may not have studied chaotic systems or complex systems in any level of detail. It might be a worthwhile effort to learn more about those systems, because they are essentially a refutation of reductionist thinking. There's a world of difference between a chaotic system like the weather and something designed and implemented by humans like a set of interconnected micro-services. I couldn't possibly hope to comprehend all the factors and variants and invariants in a weather system, but I can understand (to a certain degree) how services interact, how data flows through a human-built system, how data is represented and processed inside of a service. It's usually possible to improve parts of a system so you don't necessarily need to take the whole system's complexity into account in every decision you make. And I think we're all at least implicitly aware of it, or we wouldn't waste our time with worrying about abstraction, encapsulation, side-effects, coupling, or mutable state. We wouldn't have all these books about how to design software architecture or write clean, maintainable code. > There are too many variables to account for, and small variations in initial conditions rapidly became very divergent outcomes. If that were true, we might as well all pack up and give up. I can figure out what inputs might end up in a certain method and what outputs are possible for given inputs. And if I can't because of how the method is designed, then I can make changes that reduce the relevant state to the point where I can reason about them. There are countless variables in a system, sure, but the amount of variables at a particular point of a codebase that actually need to be accounted for are not necessarily countless. With the wrong architectural decisions, they can be countless, but that's why we avoid things like global mutable state. We are responsible for the complexity of a particular software system, which also means we have the ability to reduce or increase the complexity with the decisions we make. > I am reminded of a video where a programmer spent three years training an ai model to beat an "impossible track" in trackmania, where he finds out that chaos built into the deterministic physics engine behind the game made his pursuit much more difficult. Well, yeah, if that's the kind of system you're talking about, then sure. That's a complex system that can't be simplified or reduced, because you're literally trying to approximate real world physics. The purpose of that system is inexorably tied to its complexity. I don't envy programmers who have to deal with that form of system. > You may understand your codebase completely, but I assure you, if you released it to a large enough group of people, they could find errors and bugs in your code because they will try things that would never occur to you. I don't understand this argument. I might not be able to get rid of all bugs, but that wasn't a claim I ever made. We definitely can reduce the amount of bugs we have and the amount that we create with new code by making efforts to control the complexity affecting the code we write. > because of hidden interactions between the smaller parts of the system Going back one last time, yes, there are often hidden (or unknown) interactions between different parts of a system, but our only option isn't just to say, "well, I guess there's no way to deal with that, let's make that new feature and hope it works out". An important part of maintaining/improving a software system is uncovering these interactions and making them an explicit, visible part of the system (or removing them if they're unintended and unwanted), as well as evaluating the possible risks and consequences of decisions being made and how/when/where to mitigate them as best we can to the best of our current knowledge. Also an important part of designing these systems is reducing how different parts of a system are coupled to each other, isolating them from each other and localizing their effects as much as possible. You might not be able to reach some Platonic ideal of a simple non-complex system with no unintended interactions, but it is clearly possible to move a complex software system in that direction and there are plenty of benefits for doing so.

Sakos 2y ago

> That's the whole problem with reductionist thinking, which fails when analyzing a chaotic system or a complex system. The behavior of the whole is greater than the sum of the parts because of hidden interactions between the smaller parts of the system. There are too many variables to account for, and small variations in initial conditions rapidly became very divergent outcomes. > I get the sense that you may not have studied chaotic systems or complex systems in any level of detail. It might be a worthwhile effort to learn more about those systems, because they are essentially a refutation of reductionist thinking. There's a world of difference between a chaotic system like the weather and something designed and implemented by humans like a set of interconnected micro-services. I couldn't possibly hope to comprehend all the factors and variants and invariants in a weather system, but I can understand (to a certain degree) how services interact, how data flows through a human-built system, how data is represented and processed inside of a service. It's usually possible to improve parts of a system so you don't necessarily need to take the whole system's complexity into account in every decision you make. And I think we're all at least implicitly aware of it, or we wouldn't waste our time with worrying about abstraction, encapsulation, side-effects, coupling, or mutable state. We wouldn't have all these books about how to design software architecture or write clean, maintainable code. > There are too many variables to account for, and small variations in initial conditions rapidly became very divergent outcomes. If that were true, we might as well all pack up and give up. I can figure out what inputs might end up in a certain method and what outputs are possible for given inputs. And if I can't because of how the method is designed, then I can make changes that reduce the relevant state to the point where I can reason about them. There are countless variables in a system, sure, but the amount of variables at a particular point of a codebase that actually need to be accounted for are not necessarily countless. With the wrong architectural decisions, they can be countless, but that's why we avoid things like global mutable state. We are responsible for the complexity of a particular software system, which also means we have the ability to reduce or increase the complexity with the decisions we make. > I am reminded of a video where a programmer spent three years training an ai model to beat an "impossible track" in trackmania, where he finds out that chaos built into the deterministic physics engine behind the game made his pursuit much more difficult. Well, yeah, if that's the kind of system you're talking about, then sure. That's a complex system that can't be simplified or reduced, because you're literally trying to approximate real world physics. The purpose of that system is inexorably tied to its complexity. I don't envy programmers who have to deal with that form of system. > You may understand your codebase completely, but I assure you, if you released it to a large enough group of people, they could find errors and bugs in your code because they will try things that would never occur to you. I don't understand this argument. I might not be able to get rid of all bugs, but that wasn't a claim I ever made. We definitely can reduce the amount of bugs we have and the amount that we create with new code by making efforts to control the complexity affecting the code we write. > because of hidden interactions between the smaller parts of the system Going back one last time, yes, there are often hidden (or unknown) interactions between different parts of a system, but our only option isn't just to say, "well, I guess there's no way to deal with that, let's make that new feature and hope it works out". An important part of maintaining/improving a software system is uncovering these interactions and making them an explicit, visible part of the system (or removing them if they're unintended and unwanted), as well as evaluating the possible risks and consequences of decisions being made and how/when/where to mitigate them as best we can to the best of our current knowledge. Also an important part of designing these systems is reducing how different parts of a system are coupled to each other, isolating them from each other and localizing their effects as much as possible. You might not be able to reach some Platonic ideal of a simple non-complex system with no unintended interactions, but it is clearly possible to move a complex software system in that direction and there are plenty of benefits for doing so.