4 ms·

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

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.
  - unabst 6y ago
    > That's not what accidental/essential complexity mean in Computer Science. Of course. I was responding to the OP. This thread began with: > I have different idea about essential complexity and accidental complexity. I think examples in the article are all just accidental complexity. I was elaborating on that different idea. Everyone seems to be just reverting back to the text book and rejecting the difference not on merits, but for simply not matching. But complexity is complexity. If we really want to talk about complexity and where the unavoidable part is coming from, then it's from the layer underneath also. When speaking of complexity reduction, you cannot ignore the complexity imposed.
    - coldtea 6y ago
      Well, "I have different idea about essential complexity and accidental complexity" might mean: (a) I think we should think of essential complexity and accidental complexity differently (legit, but can be confusing, and overloads the terms). (b) I think essential complexity and accidental complexity mean something different (in general), and TFA got them wrong (e.g. because the parent doesn't know the traditional definitions of the terms, and thinks they're open to personal interpretation). >Everyone seems to be just reverting back to the text book and rejecting the difference not on merits, but for simply not matching. Yes, and I think those people are right. Whether the new idea has merit or not, it should use new terminology, to not obscure things. Then, we can discuss it on its own merit. Even so, considering it on its merit alone, I don't think it has that much (more on that below). Because it essentially amounts "if you're programming in X, you have to deal with X (e.g. bash/html/etc.) and that has some complexity". Well, duh. That's true, but it's something we already know. Whereas the accidenal/essential complexity in Brook's sense, is an important philosophical/logical distinction. >But complexity is complexity. If we really want to talk about complexity and where the unavoidable part is coming from, then it's from the layer underneath also Well, the original formulation is more useful though, because having to use bash or html is not "unavoidable". It might just be "unavoidable" because of one's employee insistence, or something like that, but that's not a computer science concern. Whereas essential complexity in Brook's sense is completely unavoidable (in the logical sense). A better and non-confusing term for what the parent describes would be, I think, "imposed complexity" or "circumstancial complexity".

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.
- unabst 6y ago
  > That's not what accidental/essential complexity mean in Computer Science. Of course. I was responding to the OP. This thread began with: > I have different idea about essential complexity and accidental complexity. I think examples in the article are all just accidental complexity. I was elaborating on that different idea. Everyone seems to be just reverting back to the text book and rejecting the difference not on merits, but for simply not matching. But complexity is complexity. If we really want to talk about complexity and where the unavoidable part is coming from, then it's from the layer underneath also. When speaking of complexity reduction, you cannot ignore the complexity imposed.
  - coldtea 6y ago
    Well, "I have different idea about essential complexity and accidental complexity" might mean: (a) I think we should think of essential complexity and accidental complexity differently (legit, but can be confusing, and overloads the terms). (b) I think essential complexity and accidental complexity mean something different (in general), and TFA got them wrong (e.g. because the parent doesn't know the traditional definitions of the terms, and thinks they're open to personal interpretation). >Everyone seems to be just reverting back to the text book and rejecting the difference not on merits, but for simply not matching. Yes, and I think those people are right. Whether the new idea has merit or not, it should use new terminology, to not obscure things. Then, we can discuss it on its own merit. Even so, considering it on its merit alone, I don't think it has that much (more on that below). Because it essentially amounts "if you're programming in X, you have to deal with X (e.g. bash/html/etc.) and that has some complexity". Well, duh. That's true, but it's something we already know. Whereas the accidenal/essential complexity in Brook's sense, is an important philosophical/logical distinction. >But complexity is complexity. If we really want to talk about complexity and where the unavoidable part is coming from, then it's from the layer underneath also Well, the original formulation is more useful though, because having to use bash or html is not "unavoidable". It might just be "unavoidable" because of one's employee insistence, or something like that, but that's not a computer science concern. Whereas essential complexity in Brook's sense is completely unavoidable (in the logical sense). A better and non-confusing term for what the parent describes would be, I think, "imposed complexity" or "circumstancial complexity".