6 ms·

In your example, the tax code is simply the abstraction layer one level down that you have no control over. So to translate your example, HTML specs would be es

by unabst 6y ago

In your example, the tax code is simply the abstraction layer one level down that you have no control over. So to translate your example, HTML specs would be essential complexity and all authored HTML would be accidental complexity to a front-end web programmer. But this makes complexity a matter of context. A browser is built using a programming language and uses interfaces provided by the OS and other libraries. This makes the browser accidental. And you can take this all the way down. Assembly is accidental with respect to the processor being essential. But now we see how complexity flows through each layer. Just as the accidental complexity of the tax code becomes essential complexity for the accountant, the accidental complexity of HTML becomes essential complexity for the web programmer. And a popular pass time is complaining how much simpler everything could be, only if. (not sure if this is what the original article had in mind but this model seems accurate)

reificator 6y ago
> So to translate your example, HTML specs would be essential complexity and all authored HTML would be accidental complexity to a front-end web programmer. The HTML specs are not essential complexity, are you joking? Accounting software that handles tax codes is the essential piece. HTML is just one approach to building an application. Even though I whip out web dev quite often, I find it scary that more and more people view it as the only option or the default approach. To say it again, the HTML specification is not essential complexity in the context of an accounting app.
- unabst 6y ago
  You're missing the point which is context. If you're the accountant, the tax code is essential. HTML is accidental. If you're the programmer, then HTML is essential. The outcome of your page is accidental. Accidental is what you have control over. Essensial is what you're forced to work with. If you're being forced to code in HTML, just as an accountant is forced to work with the tax code, the domain knowledge as provided and exposed as specs, be it HTML specs or the Tax Code cannot be altered. So if the argument is that the tax code is essential complexity for an accountant, then the analogy holds. To an accountant writing an HTML page for their firm or a one page app implementing some accounting feature for clients, HTML is all accidental. They could use anything else. What is essential to the accountant is accounting. But since we're talking programming, the situation applied to a programmer: The HTML specs are essential complexity for a web programmer. They must work with it, and cannot work around it. And this is how complexity is passed on through the layers of the system. And with the case of an accountant needing programming, the line of complexity between them is violated all the time. A web programmer hired by an accountant fails to implement good accounting software by being bound by the essential complexities of HTML. The accountant doesn't care what cannot be done because of some HTML spec. The web programmer must find ways to work around this through engineering, or compromise. This leads to further accidental complexity. edit/addendum: > I whip out web dev The moment you go with web dev, this is the act that now makes HTML specs essential. The only way to escape HTML specs is to use something else, which you cannot do if you're already decided on a web app. Just as the only way an accountant can escape the tax code would be to change professions. To align the argument with the original article, if HTML specs are half the web app, then the web app cannot be less complex than, say, half. And the only way to get there is to delete everything you did/added which is your page/program. Coding complexity can never break the essential complexity barrier, and accidental complexity in the form of your code is always a positive value. edit/addendum2: When adding a framework or library to reduce complexity, there must be a pragmatic replacement/swap of original essential complexity abstractions. The new library is positive, in that you're adding more code, and carries its essential complexity. But when the complexity of, say, jQuery can replace a priori javascript essential complexity, then we can make it out ahead. With the added complexity of replacing complexity.
  - timidger 6y ago
    I found your point hard to agree with, until I mentally replaced "HTML" with "bash" at which point I was enlightened of how important context is. Though I was hired to work with languages $X and $Y at $dayjob, many, many bugs slip through because bash is used as glue for languages $X and $Y. This was true of my last job too, the only difference is that in my current job we don't have a resident bash expert to call out issues in code review. I've always hated bash, but it's "essential" complexity when dealing with a modern Linux system. Technically it's within our domain to change, but for various reasons time and time again bash wins out as the de-facto glue holding infrastructure together.
    - unabst 6y ago
      Exactly. There is nothing you can do about bash unless you are the creators of bash. In which case, now you are dealing with whatever essential complexity it is you are forced to deal with to create your program. The program itself is all accidental using this model (the model initially outlined by the OP, which converges with the original article). Maybe "incidental complexity" would be a better term. But the model is the same.
      - coldtea 6y ago
        >You're missing the point which is context. If you're the accountant, the tax code is essential. HTML is accidental. If you're the programmer, then HTML is essential. The outcome of your page is accidental. Accidental is what you have control over. Essensial is what you're forced to work with. That's not what accidental/essential complexity mean in Computer Science. Essential Complexity is the business logic, program structure considerations, necessary tradeoffs, and so on. Accidental Complexity is BS you have to put up that's not essential to the program, but you need to handle. Things from manual memory management to setting up Webpack are "accidental complexity". It's not about the language itself. Even if you're programming in bash, bash is not "essential complexity". The complexity inherent in the task is the essential complexity (e.g. "I need to copy files from a to b, and do a processing on them, handle the case where one file is missing or when a column in the file is mangled, etc"). Bash (or whatever other tool you use) can directly help you with this essential complexity, or impose accidental complexity on top of it. E.g. cp /foo/a /bar/. for copying a from /foo to /bar has pretty much no accidental complexity. It essentially captures just what you need to do. But as the script becomes bigger and you implement more of the business logic, shit like bash messing up pipelines when a part of a pipeline fails, or dealing with its clumsy error handling, add accidental complexity.
ozim 6y ago
My main point is that all "computer stuff" is accidental complexity as I believe people in 1987 would think. It might be hard to go along with it when one is software dev and much of our lives are on the internet. But that is what Fred Brooks was writing about back then. Essential complexity idea is about real world being inherently complex and that we cannot remove that complexity by making bigger better computers. Dan is not attacking this at all, he only argues that accidental complexity is not getting easier. You argue the same thing as Dan. You want to move essential complexity to a different place. But that does not refute "Essential and Accidental complexity" in context of book it is just arguing that accidental complexity is not getting easier. Fred Brooks argues that even if you make accidental complexity easier you will not make real world easier. He was not saying that accidental complexity will get easier or that it is some kind of law that it always gets easier.
- unabst 6y ago
  Right. But I'm not just moving essential to a different place. I am describing how complexity is made essential or accidental based on where you are in the stack. It actually unifies your theory and Brooks, and I don't what others have stated as arguments against it. As an accountant staring at a computer, everything about the computer is accidental. Saying simply that the computer is accidental regardless of context is not very useful apart from for refuting Brooks.

by unabst 6y ago

reificator 6y ago

> So to translate your example, HTML specs would be essential complexity and all authored HTML would be accidental complexity to a front-end web programmer. The HTML specs are not essential complexity, are you joking? Accounting software that handles tax codes is the essential piece. HTML is just one approach to building an application. Even though I whip out web dev quite often, I find it scary that more and more people view it as the only option or the default approach. To say it again, the HTML specification is not essential complexity in the context of an accounting app.

unabst 6y ago
You're missing the point which is context. If you're the accountant, the tax code is essential. HTML is accidental. If you're the programmer, then HTML is essential. The outcome of your page is accidental. Accidental is what you have control over. Essensial is what you're forced to work with. If you're being forced to code in HTML, just as an accountant is forced to work with the tax code, the domain knowledge as provided and exposed as specs, be it HTML specs or the Tax Code cannot be altered. So if the argument is that the tax code is essential complexity for an accountant, then the analogy holds. To an accountant writing an HTML page for their firm or a one page app implementing some accounting feature for clients, HTML is all accidental. They could use anything else. What is essential to the accountant is accounting. But since we're talking programming, the situation applied to a programmer: The HTML specs are essential complexity for a web programmer. They must work with it, and cannot work around it. And this is how complexity is passed on through the layers of the system. And with the case of an accountant needing programming, the line of complexity between them is violated all the time. A web programmer hired by an accountant fails to implement good accounting software by being bound by the essential complexities of HTML. The accountant doesn't care what cannot be done because of some HTML spec. The web programmer must find ways to work around this through engineering, or compromise. This leads to further accidental complexity. edit/addendum: > I whip out web dev The moment you go with web dev, this is the act that now makes HTML specs essential. The only way to escape HTML specs is to use something else, which you cannot do if you're already decided on a web app. Just as the only way an accountant can escape the tax code would be to change professions. To align the argument with the original article, if HTML specs are half the web app, then the web app cannot be less complex than, say, half. And the only way to get there is to delete everything you did/added which is your page/program. Coding complexity can never break the essential complexity barrier, and accidental complexity in the form of your code is always a positive value. edit/addendum2: When adding a framework or library to reduce complexity, there must be a pragmatic replacement/swap of original essential complexity abstractions. The new library is positive, in that you're adding more code, and carries its essential complexity. But when the complexity of, say, jQuery can replace a priori javascript essential complexity, then we can make it out ahead. With the added complexity of replacing complexity.
- timidger 6y ago
  I found your point hard to agree with, until I mentally replaced "HTML" with "bash" at which point I was enlightened of how important context is. Though I was hired to work with languages $X and $Y at $dayjob, many, many bugs slip through because bash is used as glue for languages $X and $Y. This was true of my last job too, the only difference is that in my current job we don't have a resident bash expert to call out issues in code review. I've always hated bash, but it's "essential" complexity when dealing with a modern Linux system. Technically it's within our domain to change, but for various reasons time and time again bash wins out as the de-facto glue holding infrastructure together.
  - unabst 6y ago
    Exactly. There is nothing you can do about bash unless you are the creators of bash. In which case, now you are dealing with whatever essential complexity it is you are forced to deal with to create your program. The program itself is all accidental using this model (the model initially outlined by the OP, which converges with the original article). Maybe "incidental complexity" would be a better term. But the model is the same.
    - coldtea 6y ago
      >You're missing the point which is context. If you're the accountant, the tax code is essential. HTML is accidental. If you're the programmer, then HTML is essential. The outcome of your page is accidental. Accidental is what you have control over. Essensial is what you're forced to work with. That's not what accidental/essential complexity mean in Computer Science. Essential Complexity is the business logic, program structure considerations, necessary tradeoffs, and so on. Accidental Complexity is BS you have to put up that's not essential to the program, but you need to handle. Things from manual memory management to setting up Webpack are "accidental complexity". It's not about the language itself. Even if you're programming in bash, bash is not "essential complexity". The complexity inherent in the task is the essential complexity (e.g. "I need to copy files from a to b, and do a processing on them, handle the case where one file is missing or when a column in the file is mangled, etc"). Bash (or whatever other tool you use) can directly help you with this essential complexity, or impose accidental complexity on top of it. E.g. cp /foo/a /bar/. for copying a from /foo to /bar has pretty much no accidental complexity. It essentially captures just what you need to do. But as the script becomes bigger and you implement more of the business logic, shit like bash messing up pipelines when a part of a pipeline fails, or dealing with its clumsy error handling, add accidental complexity.

ozim 6y ago

My main point is that all "computer stuff" is accidental complexity as I believe people in 1987 would think. It might be hard to go along with it when one is software dev and much of our lives are on the internet. But that is what Fred Brooks was writing about back then. Essential complexity idea is about real world being inherently complex and that we cannot remove that complexity by making bigger better computers. Dan is not attacking this at all, he only argues that accidental complexity is not getting easier. You argue the same thing as Dan. You want to move essential complexity to a different place. But that does not refute "Essential and Accidental complexity" in context of book it is just arguing that accidental complexity is not getting easier. Fred Brooks argues that even if you make accidental complexity easier you will not make real world easier. He was not saying that accidental complexity will get easier or that it is some kind of law that it always gets easier.

unabst 6y ago
Right. But I'm not just moving essential to a different place. I am describing how complexity is made essential or accidental based on where you are in the stack. It actually unifies your theory and Brooks, and I don't what others have stated as arguments against it. As an accountant staring at a computer, everything about the computer is accidental. Saying simply that the computer is accidental regardless of context is not very useful apart from for refuting Brooks.