5 ms·

Complexity is not conserved. It is a bound. A solution can not be simpler than the problem, when both are viewed holistically and complexity is properly underst

by jerf 7y ago

Complexity is not conserved. It is a bound. A solution can not be simpler than the problem, when both are viewed holistically and complexity is properly understood. (Yeah, I'm handwaving, but at least I acknowledge it. I don't want to write twelve paragraphs defining "complexity" right now, because my real point is....) But the solution sure can be more complicated than the problem.

tacon 7y ago
Fred Brooks wrote a book about complexity, accidental and essential. Essential complexity is the lower bound to which you refer, and the hard limit that prevents major advances in programmer productivity. https://en.wikipedia.org/wiki/No_Silver_Bullet https://en.wikipedia.org/wiki/No_Silver_Bullet
jfengel 7y ago
That is more or less what TFA says: "Every application has an inherent amount of irreducible complexity." "Irreducible" means a bound, but it does not mean a constant. The name is misleading to a scientist, who has a specific understanding of what "conservation" means. And in particular, a very specific notion of what a "conservation law" is. Which this does not follow. Getting past the name, it's a useful adage. But the name adds unneeded complexity, placing a burden on people who are forced to learn a different intention for a well-understood term.
- contextfree 7y ago
  If the complexity is truly irreducible, is it possible to truly hide it from the user either?
  - jerf 7y ago
    Continuing to handwave, if the system as a whole is something like "user complexity + program complexity >= problem complexity", you can indeed hide it from the user in many cases by pulling it into the program itself. Otherwise, programs would have no utility at all. That's essentially their whole purpose, is to pull it away from the user by putting it in the program.
  - jfengel 7y ago
    Probably not, but you are pointing out kind of an oddity in the adage. Complexity should always live on the side of the developer, not the user. Any design choice that says, "We could figure out how to do this, but we didn't, so we'll make the user do it for us" is just outright bad. That's not an adage; that's just an injunction not to be a bad designer. What's more interesting is that even within the domain of the user space, there is an irreducible complexity. You can push it around, but you can't make it go away. Figuring which users you will inconvenience, how often, and how bad it will be -- that's the artistry.
  - goto11 7y ago
    You can replace a hard disk with a solid state drive, and most users would not notice a thing except it might be a bit faster and less noisy. An enormous amount of complexity is hidden behind a simple interface.
goto11 7y ago
Isn't that the distinction between accidental and essential complexity? A solution cannot be simpler than the essential complexity of the problem, but it can surely be more complex by adding accidental complexity.
- jayd16 7y ago
  This is kind of a word game though. As soon as you find a way to lower complexity it becomes the new essential complexity until someone lowers it again.
  - goto11 7y ago
    Are you arguing there is no such thing as essential complexity? In that case it would be possible to compress any program down to one bit, without moving the complexity elsewhere.
crimsonalucard 7y ago
>A solution can not be simpler than the problem. Problem: (4 primitives) 1 + 1 + 1 + 1 Solution (one primitive): 4 If amount of primitives defines complexity you are wrong. What's going on here is that you are using a different definition of complexity to construct your statement above. Most humans intuitively recognize your statement along with mine. The issue here is that before we can even talk about complexity we have to come up with a formal definition that fits all forms of our intuition about what complexity actually is. Otherwise all arguments can become circular and pointless as everyone is talking about different things. What is the formal definition of complexity? What is the thing that is being preserved here?
- jessermeyer 7y ago
  What you call the problem is actually the specification of the solution, which is the point. What you call the solution is another representation of the solution, but lacks the specification, so you _cannot_ use it to show that it _is_ a solution.
  - crimsonalucard 7y ago
    https://news.ycombinator.com/item?id=22378553 https://news.ycombinator.com/item?id=22378553
- BoiledCabbage 7y ago
  I disagree with the above. If you're listing 1 + 1 + 1 + 1 as 4 primitives (I think it's actually more once you include the primitive of addition), I don't think that 4 is the solution. The solution is a written up program that works on any integer that when run this particular sequence produces the value 4. And that solution/program is significantly more complex than 1+1+1+1. Or alternatively if you say the program can't run on any other values, just that specific one so you can hardcode the result of the program to be "4", then I'd argue there initially aren't 4 primitives. there is one single primitive the entire entity "1+1+1+1" which is equivalent in inherent complexity to the primitive "4". Regardless of how complex we choose to represent it (ie with more characters or fewer), conceptually it's a single "primite" value input and it produces a single primitive value output.
__s 7y ago
Doesn't P=NP say otherwise? Given the solution, the problem becomes polynomial time to verify. Hindsight 2020
- thedirt0115 7y ago
  I think the comment was a little tongue-in-cheek -- like FizzBuzz is a problem without much inherent complexity, but you can certainly you make an overly complex solution: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
thrower123 7y ago
The solution can sometimes be simpler than the problem, if the problem is redefined so that it isn't as complex. Quite often this is the case when tunnel-visioned on a particular process and focusing on how to do that thing. Stepping back and thinking about why or what the end goal actually is, and then doing something else, is often the only real way to meaningfully reduce complexity.

by jerf 7y ago

tacon 7y ago

Fred Brooks wrote a book about complexity, accidental and essential. Essential complexity is the lower bound to which you refer, and the hard limit that prevents major advances in programmer productivity. https://en.wikipedia.org/wiki/No_Silver_Bullet https://en.wikipedia.org/wiki/No_Silver_Bullet

jfengel 7y ago

That is more or less what TFA says: "Every application has an inherent amount of irreducible complexity." "Irreducible" means a bound, but it does not mean a constant. The name is misleading to a scientist, who has a specific understanding of what "conservation" means. And in particular, a very specific notion of what a "conservation law" is. Which this does not follow. Getting past the name, it's a useful adage. But the name adds unneeded complexity, placing a burden on people who are forced to learn a different intention for a well-understood term.

contextfree 7y ago
If the complexity is truly irreducible, is it possible to truly hide it from the user either?
- jerf 7y ago
  Continuing to handwave, if the system as a whole is something like "user complexity + program complexity >= problem complexity", you can indeed hide it from the user in many cases by pulling it into the program itself. Otherwise, programs would have no utility at all. That's essentially their whole purpose, is to pull it away from the user by putting it in the program.
- jfengel 7y ago
  Probably not, but you are pointing out kind of an oddity in the adage. Complexity should always live on the side of the developer, not the user. Any design choice that says, "We could figure out how to do this, but we didn't, so we'll make the user do it for us" is just outright bad. That's not an adage; that's just an injunction not to be a bad designer. What's more interesting is that even within the domain of the user space, there is an irreducible complexity. You can push it around, but you can't make it go away. Figuring which users you will inconvenience, how often, and how bad it will be -- that's the artistry.
- goto11 7y ago
  You can replace a hard disk with a solid state drive, and most users would not notice a thing except it might be a bit faster and less noisy. An enormous amount of complexity is hidden behind a simple interface.

goto11 7y ago

Isn't that the distinction between accidental and essential complexity? A solution cannot be simpler than the essential complexity of the problem, but it can surely be more complex by adding accidental complexity.

jayd16 7y ago
This is kind of a word game though. As soon as you find a way to lower complexity it becomes the new essential complexity until someone lowers it again.
- goto11 7y ago
  Are you arguing there is no such thing as essential complexity? In that case it would be possible to compress any program down to one bit, without moving the complexity elsewhere.

crimsonalucard 7y ago

>A solution can not be simpler than the problem. Problem: (4 primitives) 1 + 1 + 1 + 1 Solution (one primitive): 4 If amount of primitives defines complexity you are wrong. What's going on here is that you are using a different definition of complexity to construct your statement above. Most humans intuitively recognize your statement along with mine. The issue here is that before we can even talk about complexity we have to come up with a formal definition that fits all forms of our intuition about what complexity actually is. Otherwise all arguments can become circular and pointless as everyone is talking about different things. What is the formal definition of complexity? What is the thing that is being preserved here?

jessermeyer 7y ago
What you call the problem is actually the specification of the solution, which is the point. What you call the solution is another representation of the solution, but lacks the specification, so you _cannot_ use it to show that it _is_ a solution.
- crimsonalucard 7y ago
  https://news.ycombinator.com/item?id=22378553 https://news.ycombinator.com/item?id=22378553
BoiledCabbage 7y ago
I disagree with the above. If you're listing 1 + 1 + 1 + 1 as 4 primitives (I think it's actually more once you include the primitive of addition), I don't think that 4 is the solution. The solution is a written up program that works on any integer that when run this particular sequence produces the value 4. And that solution/program is significantly more complex than 1+1+1+1. Or alternatively if you say the program can't run on any other values, just that specific one so you can hardcode the result of the program to be "4", then I'd argue there initially aren't 4 primitives. there is one single primitive the entire entity "1+1+1+1" which is equivalent in inherent complexity to the primitive "4". Regardless of how complex we choose to represent it (ie with more characters or fewer), conceptually it's a single "primite" value input and it produces a single primitive value output.

__s 7y ago

Doesn't P=NP say otherwise? Given the solution, the problem becomes polynomial time to verify. Hindsight 2020

thedirt0115 7y ago
I think the comment was a little tongue-in-cheek -- like FizzBuzz is a problem without much inherent complexity, but you can certainly you make an overly complex solution: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

thrower123 7y ago

The solution can sometimes be simpler than the problem, if the problem is redefined so that it isn't as complex. Quite often this is the case when tunnel-visioned on a particular process and focusing on how to do that thing. Stepping back and thinking about why or what the end goal actually is, and then doing something else, is often the only real way to meaningfully reduce complexity.