5 ms·

Not quite sure. Nobody says that rocket science is unnecessarily complex, and that it should be solved with simple math. I am waiting for the application of th

Not quite sure. Nobody says that rocket science is unnecessarily complex, and that it should be solved with simple math. I am waiting for the application of the proposed solutions for software complexity. I have been for a long time. Nobody really came up with anything, even though many have complained about it.

Verdex 5y ago
So far I haven't even seen anyone able to define what complexity is. We just have code smells (like the code makes your tummy hurt?) and we've got "best practices" with zero explanation where they came from or why they're supposed to work.
- Taek 5y ago
  Software complexity is how long it takes an engineer to fully understand the form and function of a piece of code, and all the way the ways that code interacts with the rest of the universe.
  - Verdex 5y ago
    Okay. But that's mostly poetics. This definition means that complexity is completely dependent on the individual. And also probably on how distracted they are and how much sleep they had and how much coffee they've consumed. I can't accept a definition that makes code complexity go up if the engineer looking at it had to stay up late with a sick toddler. Or that makes a bunch of spaghetti obfuscated code go down because the engineer who obfuscated it put in this one neat trick that only they know about. Also "the ways that code interacts with the rest of the universe" pretty much pegs all software at a complexity of infinity (got to take into account those gamma rays flipping bits). Not particularly useful beyond selling an Excell spreadsheet to management that's going to give an "accurate estimation" because this time is going to be different.
    - d110af5ccf 5y ago
      > This definition means that complexity is completely dependent on the individual. ... I can't accept ... Isn't this exactly how it works though? Many things look hopelessly complex until you gain additional knowledge about adjacent concepts. Consider how an elegant piece of Haskell code looks to an outsider who isn't yet proficient with the type system. Consider how difficult it is to make sense of call/cc the first time you encounter the concept of continuations, even though the underlying principle is incredibly simple. Consider how apparently difficult it is for many seasoned developers to adjust to the Rust borrow checker. It's almost like you need a "frame of reference" for judging complexity, analogous to physical systems. The velocity of an object is entirely dependent on the observer ...
      - Verdex 5y ago
        I don't think so. To be sure, familiarly can make things easier. So APL looks complex until you get used to it. However, intercal is designed to be purposefully incomprehensible. You can make it (objectively) incrementally less complex by removing the "please" rule, for example. Similarly you can make it objectively more complex (in a way that nobody can get used to) by randomly choosing a number at compile time and then requiring every file to have a "please" on that line. Familiarity can make complexity easier to deal with but there exists objective complexity that (all things being equal) will make things easier to deal with if it were addressed.
        d110af5ccf 5y ago
        You acknowledge that APL looks complex until you get used to it. So then how can you objectively score the complexity of code written in it? Won't the precise numerical value inevitably depend on the internal state of the individual reading the code? Ignoring this inconvenient fact would seem to lead to fairly useless metrics. I can see where the notion of scoring overall complexity can be a useful cognitive tool when working alongside people with similar backgrounds to yourself but I don't think there's anything objective about it at all. In fact, I don't think that an objective measure can exist in the general sense. Note that all I'm arguing here is that any useful software complexity metric will inevitably exhibit a dependence on the individual. I agree that intentional obfuscation adds complexity in an objective sense but would argue that there's no objective way to quantify how much it adds and that any such score will inevitably vary between observers. I think Code Golf is a relevant example here. Programs of minimal size whose textual representation often looks almost like line noise. They are simple and elegant in the sense that they are small; the meaning per character has been maximized to the best of the author's ability. However, they are also highly complex in the sense that the typical human will find them incredibly difficult to make sense of.
  - bluepizza 5y ago
    > an engineer to fully understand the form and function of a piece of code Which is quite impossible. This kind of understanding is a bunch of mental levers, trying to Nicolas Cage every possible scenario to a piece of code. That's why we have ideas such as clean code and TDD - to ensure that we don't have to fully understand the form and function of a piece of code. Instead, we can be humans, worry about the general design, and allow machines to validate it.
- apocolyps6 5y ago
  I think this is the sort of thing that enters the collective consciousness and then gets generalized, but code smells were originally pretty specific anti-patterns that had specific fixes. All from this book if I recall correctly https://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485672 https://www.amazon.com/Refactoring-Improving-Design-Existing...
- dredmorbius 5y ago
  Complexity has multiple dimensions and aspects, some of which conflict with one another. Charles Perrow’s model in his book Normal Accidents is Interactions vs. Coupling, though that seems overly simplistic. Extending that a bit: https://joindiaspora.com/posts/97208f300fc4013901a3002590d8e506 https://joindiaspora.com/posts/97208f300fc4013901a3002590d8e...
  - Verdex 5y ago
    Cool. I've noticed that general program complexity seems to be a topic that everyone acknowledges, but nobody tries to frame objectively. Except for a few people at the fringes. I'm not sure that I understand and/or agree with this link. However, I've written and talked about this topic in the past and the response that I've gotten is usually some variation of, "Cool, but I'm not sure that I get it." It feels kind of like the blind men describing the elephant. People are grasping at something that's probably real, but it's so big that it's going to take a long time before we finally manage to pin down anything concrete. The effort has to start somewhere though. Other interesting occurrences: http://curtclifton.net/papers/MoseleyMarks06a.pdf http://curtclifton.net/papers/MoseleyMarks06a.pdf (out of the tar pit) https://www.sonarsource.com/docs/CognitiveComplexity.pdf https://www.sonarsource.com/docs/CognitiveComplexity.pdf (semantic compression) https://www.progsbase.com/blog/flow-charts-of-programming-language-constructs/ https://www.progsbase.com/blog/flow-charts-of-programming-la... I'm not sure any attempt I've seen covers everything, but I think it's interesting that people keep trying to describe something that looks suspiciously similar.

Verdex 5y ago

So far I haven't even seen anyone able to define what complexity is. We just have code smells (like the code makes your tummy hurt?) and we've got "best practices" with zero explanation where they came from or why they're supposed to work.

Taek 5y ago
Software complexity is how long it takes an engineer to fully understand the form and function of a piece of code, and all the way the ways that code interacts with the rest of the universe.
- Verdex 5y ago
  Okay. But that's mostly poetics. This definition means that complexity is completely dependent on the individual. And also probably on how distracted they are and how much sleep they had and how much coffee they've consumed. I can't accept a definition that makes code complexity go up if the engineer looking at it had to stay up late with a sick toddler. Or that makes a bunch of spaghetti obfuscated code go down because the engineer who obfuscated it put in this one neat trick that only they know about. Also "the ways that code interacts with the rest of the universe" pretty much pegs all software at a complexity of infinity (got to take into account those gamma rays flipping bits). Not particularly useful beyond selling an Excell spreadsheet to management that's going to give an "accurate estimation" because this time is going to be different.
  - d110af5ccf 5y ago
    > This definition means that complexity is completely dependent on the individual. ... I can't accept ... Isn't this exactly how it works though? Many things look hopelessly complex until you gain additional knowledge about adjacent concepts. Consider how an elegant piece of Haskell code looks to an outsider who isn't yet proficient with the type system. Consider how difficult it is to make sense of call/cc the first time you encounter the concept of continuations, even though the underlying principle is incredibly simple. Consider how apparently difficult it is for many seasoned developers to adjust to the Rust borrow checker. It's almost like you need a "frame of reference" for judging complexity, analogous to physical systems. The velocity of an object is entirely dependent on the observer ...
    - Verdex 5y ago
      I don't think so. To be sure, familiarly can make things easier. So APL looks complex until you get used to it. However, intercal is designed to be purposefully incomprehensible. You can make it (objectively) incrementally less complex by removing the "please" rule, for example. Similarly you can make it objectively more complex (in a way that nobody can get used to) by randomly choosing a number at compile time and then requiring every file to have a "please" on that line. Familiarity can make complexity easier to deal with but there exists objective complexity that (all things being equal) will make things easier to deal with if it were addressed.
      - d110af5ccf 5y ago
        You acknowledge that APL looks complex until you get used to it. So then how can you objectively score the complexity of code written in it? Won't the precise numerical value inevitably depend on the internal state of the individual reading the code? Ignoring this inconvenient fact would seem to lead to fairly useless metrics. I can see where the notion of scoring overall complexity can be a useful cognitive tool when working alongside people with similar backgrounds to yourself but I don't think there's anything objective about it at all. In fact, I don't think that an objective measure can exist in the general sense. Note that all I'm arguing here is that any useful software complexity metric will inevitably exhibit a dependence on the individual. I agree that intentional obfuscation adds complexity in an objective sense but would argue that there's no objective way to quantify how much it adds and that any such score will inevitably vary between observers. I think Code Golf is a relevant example here. Programs of minimal size whose textual representation often looks almost like line noise. They are simple and elegant in the sense that they are small; the meaning per character has been maximized to the best of the author's ability. However, they are also highly complex in the sense that the typical human will find them incredibly difficult to make sense of.
- bluepizza 5y ago
  > an engineer to fully understand the form and function of a piece of code Which is quite impossible. This kind of understanding is a bunch of mental levers, trying to Nicolas Cage every possible scenario to a piece of code. That's why we have ideas such as clean code and TDD - to ensure that we don't have to fully understand the form and function of a piece of code. Instead, we can be humans, worry about the general design, and allow machines to validate it.
apocolyps6 5y ago
I think this is the sort of thing that enters the collective consciousness and then gets generalized, but code smells were originally pretty specific anti-patterns that had specific fixes. All from this book if I recall correctly https://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485672 https://www.amazon.com/Refactoring-Improving-Design-Existing...
dredmorbius 5y ago
Complexity has multiple dimensions and aspects, some of which conflict with one another. Charles Perrow’s model in his book Normal Accidents is Interactions vs. Coupling, though that seems overly simplistic. Extending that a bit: https://joindiaspora.com/posts/97208f300fc4013901a3002590d8e506 https://joindiaspora.com/posts/97208f300fc4013901a3002590d8e...
- Verdex 5y ago
  Cool. I've noticed that general program complexity seems to be a topic that everyone acknowledges, but nobody tries to frame objectively. Except for a few people at the fringes. I'm not sure that I understand and/or agree with this link. However, I've written and talked about this topic in the past and the response that I've gotten is usually some variation of, "Cool, but I'm not sure that I get it." It feels kind of like the blind men describing the elephant. People are grasping at something that's probably real, but it's so big that it's going to take a long time before we finally manage to pin down anything concrete. The effort has to start somewhere though. Other interesting occurrences: http://curtclifton.net/papers/MoseleyMarks06a.pdf http://curtclifton.net/papers/MoseleyMarks06a.pdf (out of the tar pit) https://www.sonarsource.com/docs/CognitiveComplexity.pdf https://www.sonarsource.com/docs/CognitiveComplexity.pdf (semantic compression) https://www.progsbase.com/blog/flow-charts-of-programming-language-constructs/ https://www.progsbase.com/blog/flow-charts-of-programming-la... I'm not sure any attempt I've seen covers everything, but I think it's interesting that people keep trying to describe something that looks suspiciously similar.