Re:Please do not attempt to simplify this code
by marvin on Friday December 28, 2018 @05:24AM
(#18775989)
Well said. I feel that 80% of this thread is people talking past each other, with different assumptions about what the code in question is going to do.
Re:Please do not attempt to simplify this code
by punnerud on Thursday December 27, 2018 @07:05PM
(#18773791)
Note to others: 3rd order is not necessarily 10^10^10. It can easily be 10^100^1000.
Re:Please do not attempt to simplify this code
by aardvark291 on Friday December 28, 2018 @03:00AM
(#18775413)
I hope you mean x (multiplication) rather than ^ (exponentiation). If we're talking about fanout (each of 10 items of has 10 subitems, each of which has 10 subitems), multiplication is the relevant operation. And 10^(10^10) or (10^10)^10 is a hopelessly, uselessly, inconceivably large number. (Exponentiation is not associative; 3^(3^3)=3^9= 19683 while (3^3)^3=9^3=729.)
Re:Please do not attempt to simplify this code
by AlexCoventry on Friday December 28, 2018 @12:24PM
(#18778060)
I took it to mean something fairly vague about potential super-exponential blowup in the complexity of the states you have to reason about, when you have to reason directly about third-order effects in a code base.
With code that far down in the inner loops of mission critical code, the dominant time cost isn't really writing or even understanding the code, it's ramping up on the nuances of the scenarios you serve, checking the direct effects of your changes, and then checking the second order and third order effects of your changes.
When your code is so far down that every change you make has third order effects, it's a lot easier to maintain code that is meticulously commented and written for maximum thoroughness explicitly baked into the file in front of you, because you're much more likely to miss the nuances if you just finished piecing together ten different files to figure out how the happy path works.