5 ms·

This argument always strikes me as a cop out. Software is bad due to historical accidents, cultural factors, and short term economic incentives, not irreducible

This argument always strikes me as a cop out. Software is bad due to historical accidents, cultural factors, and short term economic incentives, not irreducible mathematical complexity.

PaulHoule 5y ago
There's a deep principle, I think, that required backwards compatibility eliminates the possibility of needed reform. One could imagine a "bloat free" OS that eliminates the overhead of the paging MMU and has rationalized APIs and does everything differently. But you need a userspace and you're going to want to run (say) vi as a text editor and you need a shell so you get zsh to run, and you want "grep" and "awk", etc. So you have to emulate the old API and in the process of doing that all the old bloat goes back in...
- tech2 5y ago
  The same thing happened with BeOS many years ago. Initially their programming model was a thing of beauty. Then the POSIX layer arrived so that people could do exactly as you described. Some things should remain different.
tenaciousDaniel 5y ago
My interpretation of the above comment isn't that software will always be "bad", more that software will never be perfect. If software were perfect, then it would scale 1:1 with the complexity of the problem at hand (no matter how you define it). No human is perfect; humans write software; therefore software will be imperfect.
- runawaybottle 5y ago
  Misanthropes generally resort to this world view with respect to humanity because we (outing myself) believe human nature always reveals itself (eg - line up for toilet paper at the beginning of the pandemic). We are resigned to the feeling that ‘it’s never gonna get fixed’. It’s not a good way to be, and to see this worldview permeate into objective areas of life is even more depressing. Misanthropy kind of absolves humanity of it’s nature. What I don’t like to see in software is that type of absolution for code we know is obviously not pragmatic. It’s a tough debate because often the perpetrators of complex abstraction layers don’t believe it’s bad (any number of us could have been the guilty party at some point or another): I think we should still try to be optimistic about openly debating complexity, or else we risk allowing misanthropic perceptions to enter this realm too - ‘people just suck at programming, so be it’.
  - tenaciousDaniel 5y ago
    On the subject of cultural resignation, I'm totally with you. It's not a good way to go about life. Though I don't think it's required to come away from my comment with that conclusion. There's plenty of space between "things will never be perfect" and "things will never be better". Software can definitely be better, it's just important to not worry too much about perfection - it really is the enemy of the good.
    - sitkack 5y ago
      I am a naively optimistic stoic nihilist that knows humans can do waaay better than we are, at basically everything. But one can hold both of the opposing views of what the upscussion is talking about in human nature and misanthropy. Good architecture encourages the right decisions. So we can both accept that human nature will "come out" and also strive to help our fellow humans make the best possible decisions in light of that. Anything else is not being true to ourselves and the situation.
- qayxc 5y ago
  It goes deeper than that. There is intrinsic irreducible complexity that comes with many problems and there's no way to fix that. Software solutions also cannot scale linearly with the complexity of the problem. In fact, it's provably outright impossible to even calculate the complexity of a problem in general, let alone find the optimal (as in least complex) solution (see Komolgorov complexity).
bluepizza 5y ago
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 ...
dasil003 5y ago
Depends how you look at it. Reconciling input from a hundred different stakeholders all of whom have a slightly different mental model and worldview can definitely lead to mathematical complexity. Is it irreducible? It's sort of a philosophical question as you could keep hammering away at them to build a shared understanding and pare things away at the edges, and you could spend infinite time at this, but in the end you might reach a point where stakeholders would prefer it to fail than to make another concession.
- blowski 5y ago
  > in the end you might reach a point where stakeholders would prefer it to fail than to make another concession Or even spend any more time talking to you. Despite being a stakeholder, they may not care about failure so long as they don’t get the blame.
- Aeolun 5y ago
  > in the end you might reach a point where stakeholders would prefer it to fail than to make another concession In this case your project will fail regardless. You just won’t have wasted person-centuries of development time.
brazzy 5y ago
I didn't say "irreducible" at all - just that software naturally gravitates towards nonessential complexity. Avoiding that takes skill, hard work, constant vigilance, and the humility, willingness and ability to go back and redo things. Because it's easy to get it wrong and overengineer something in the name of managing complexity, or because you didn't know or misunderstood something about the problem domain. There's your "historical accidents". And "short term economic incentives" is just a dismissive way to say that having working software now is a hell of a lot more useful than perfect software at an unknowable time in the future.

This argument always strikes me as a cop out. Software is bad due to historical accidents, cultural factors, and short term economic incentives, not irreducible mathematical complexity.

PaulHoule 5y ago

There's a deep principle, I think, that required backwards compatibility eliminates the possibility of needed reform. One could imagine a "bloat free" OS that eliminates the overhead of the paging MMU and has rationalized APIs and does everything differently. But you need a userspace and you're going to want to run (say) vi as a text editor and you need a shell so you get zsh to run, and you want "grep" and "awk", etc. So you have to emulate the old API and in the process of doing that all the old bloat goes back in...

tech2 5y ago
The same thing happened with BeOS many years ago. Initially their programming model was a thing of beauty. Then the POSIX layer arrived so that people could do exactly as you described. Some things should remain different.

tenaciousDaniel 5y ago

My interpretation of the above comment isn't that software will always be "bad", more that software will never be perfect. If software were perfect, then it would scale 1:1 with the complexity of the problem at hand (no matter how you define it). No human is perfect; humans write software; therefore software will be imperfect.

runawaybottle 5y ago
Misanthropes generally resort to this world view with respect to humanity because we (outing myself) believe human nature always reveals itself (eg - line up for toilet paper at the beginning of the pandemic). We are resigned to the feeling that ‘it’s never gonna get fixed’. It’s not a good way to be, and to see this worldview permeate into objective areas of life is even more depressing. Misanthropy kind of absolves humanity of it’s nature. What I don’t like to see in software is that type of absolution for code we know is obviously not pragmatic. It’s a tough debate because often the perpetrators of complex abstraction layers don’t believe it’s bad (any number of us could have been the guilty party at some point or another): I think we should still try to be optimistic about openly debating complexity, or else we risk allowing misanthropic perceptions to enter this realm too - ‘people just suck at programming, so be it’.
- tenaciousDaniel 5y ago
  On the subject of cultural resignation, I'm totally with you. It's not a good way to go about life. Though I don't think it's required to come away from my comment with that conclusion. There's plenty of space between "things will never be perfect" and "things will never be better". Software can definitely be better, it's just important to not worry too much about perfection - it really is the enemy of the good.
  - sitkack 5y ago
    I am a naively optimistic stoic nihilist that knows humans can do waaay better than we are, at basically everything. But one can hold both of the opposing views of what the upscussion is talking about in human nature and misanthropy. Good architecture encourages the right decisions. So we can both accept that human nature will "come out" and also strive to help our fellow humans make the best possible decisions in light of that. Anything else is not being true to ourselves and the situation.
qayxc 5y ago
It goes deeper than that. There is intrinsic irreducible complexity that comes with many problems and there's no way to fix that. Software solutions also cannot scale linearly with the complexity of the problem. In fact, it's provably outright impossible to even calculate the complexity of a problem in general, let alone find the optimal (as in least complex) solution (see Komolgorov complexity).

bluepizza 5y ago

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 ...

dasil003 5y ago

Depends how you look at it. Reconciling input from a hundred different stakeholders all of whom have a slightly different mental model and worldview can definitely lead to mathematical complexity. Is it irreducible? It's sort of a philosophical question as you could keep hammering away at them to build a shared understanding and pare things away at the edges, and you could spend infinite time at this, but in the end you might reach a point where stakeholders would prefer it to fail than to make another concession.

blowski 5y ago
> in the end you might reach a point where stakeholders would prefer it to fail than to make another concession Or even spend any more time talking to you. Despite being a stakeholder, they may not care about failure so long as they don’t get the blame.
Aeolun 5y ago
> in the end you might reach a point where stakeholders would prefer it to fail than to make another concession In this case your project will fail regardless. You just won’t have wasted person-centuries of development time.

brazzy 5y ago

I didn't say "irreducible" at all - just that software naturally gravitates towards nonessential complexity. Avoiding that takes skill, hard work, constant vigilance, and the humility, willingness and ability to go back and redo things. Because it's easy to get it wrong and overengineer something in the name of managing complexity, or because you didn't know or misunderstood something about the problem domain. There's your "historical accidents". And "short term economic incentives" is just a dismissive way to say that having working software now is a hell of a lot more useful than perfect software at an unknowable time in the future.