3 ms·

That’s not reducing complexity at all though, just hiding it… Which is fine for someone working a job that doesn’t need to understand all the stuff behind the

That’s not reducing complexity at all though, just hiding it… Which is fine for someone working a job that doesn’t need to understand all the stuff behind the curtain, but not fine for anyone who actually wants to understand the overall system.

coldtea 2y ago
>That’s not reducing complexity at all though, just hiding it… It's a representation. The actual thing will still have the whole complexity. What is reduced is how much complexity we take in when looking at what the thing does. When someone wants to get an idea of what the thing does, as opposed to getting into the minutiae of every subcase, such a high level view is a better fit.
- MichaelZuo 2y ago
  Regardless, it's not suitable for those who do need to grasp the entirety...
  - coldtea 2y ago
    Above some point they can just check the code. People looking at flowcharts usually don't need the entirety. Especially as the flowchart could even be out of date, or miss some of the code-level subleties.
    - MichaelZuo 2y ago
      Why would those seeking to grasp the entirety use a less efficient and more cumbersome method, than just looking at the full flowchart in the first place? (assuming it exists) And I don’t see why it matters if it’s only a handful of people, information products can still be created for their needs, if so decided.
      - dvqc 2y ago
        Because the code is the entirety of the process. Any graph can be wrong, but the code cannot, because it is the implementation. The purpose of a graph is to allow the visualization of the process in an understandable manner. If it doesn't abstract away much from the code, you might as well look at the code directly
        MichaelZuo 2y ago
        No? Code is not always the same as the process or what the machine actually does... There are hundreds of posible factors from bitflips to a cable getting loose in a socket that could change either. e.g. There clearly can be a computer configured with enough memory and dense enough memory that at least one bitflip is practically guaranteed in a certain unit time, so the actual process has to include that. So the code is an abstraction just like the flowchart.
        dvqc 2y ago
        You have processes more formal and thorough than their code implementation? Really? At the end of the day, is it the cover-every-possible-bitflip-and-gamma-ray-bursts process that produces results out of thin air, or is it the machine running the code? I don't believe this is arguing in good faith.
        MichaelZuo 2y ago
        I never said I had such processes? You seem to be making a logical fallacy to impute that it somehow must exist. e.g. “ The absence of evidence is not evidence of absence.” Also why would any other reader, including me, care about beliefs about certain words more than the actual words?
        coldtea 2y ago
        >Code is not always the same as the process or what the machine actually does... You started with why aren't they "just looking at the full flowchart [to understand the entirety]". And the parent wrote that because the flowchart is not the entirety, the code is. Do you think this retort you make above is refuting the parent's point? If anything, it expands it, going further against your original point: that's why they're not just looking at the full flowchart. And, yes, "code is an abstraction, just like the flowchart", but code is the abstraction the programmer controls and tries to summarize and understand. The flowchart is a higher level abstraction of an abstraction.

coldtea 2y ago

>That’s not reducing complexity at all though, just hiding it… It's a representation. The actual thing will still have the whole complexity. What is reduced is how much complexity we take in when looking at what the thing does. When someone wants to get an idea of what the thing does, as opposed to getting into the minutiae of every subcase, such a high level view is a better fit.

MichaelZuo 2y ago
Regardless, it's not suitable for those who do need to grasp the entirety...
- coldtea 2y ago
  Above some point they can just check the code. People looking at flowcharts usually don't need the entirety. Especially as the flowchart could even be out of date, or miss some of the code-level subleties.
  - MichaelZuo 2y ago
    Why would those seeking to grasp the entirety use a less efficient and more cumbersome method, than just looking at the full flowchart in the first place? (assuming it exists) And I don’t see why it matters if it’s only a handful of people, information products can still be created for their needs, if so decided.
    - dvqc 2y ago
      Because the code is the entirety of the process. Any graph can be wrong, but the code cannot, because it is the implementation. The purpose of a graph is to allow the visualization of the process in an understandable manner. If it doesn't abstract away much from the code, you might as well look at the code directly
      - MichaelZuo 2y ago
        No? Code is not always the same as the process or what the machine actually does... There are hundreds of posible factors from bitflips to a cable getting loose in a socket that could change either. e.g. There clearly can be a computer configured with enough memory and dense enough memory that at least one bitflip is practically guaranteed in a certain unit time, so the actual process has to include that. So the code is an abstraction just like the flowchart.
        dvqc 2y ago
        You have processes more formal and thorough than their code implementation? Really? At the end of the day, is it the cover-every-possible-bitflip-and-gamma-ray-bursts process that produces results out of thin air, or is it the machine running the code? I don't believe this is arguing in good faith.
        MichaelZuo 2y ago
        I never said I had such processes? You seem to be making a logical fallacy to impute that it somehow must exist. e.g. “ The absence of evidence is not evidence of absence.” Also why would any other reader, including me, care about beliefs about certain words more than the actual words?
        coldtea 2y ago
        >Code is not always the same as the process or what the machine actually does... You started with why aren't they "just looking at the full flowchart [to understand the entirety]". And the parent wrote that because the flowchart is not the entirety, the code is. Do you think this retort you make above is refuting the parent's point? If anything, it expands it, going further against your original point: that's why they're not just looking at the full flowchart. And, yes, "code is an abstraction, just like the flowchart", but code is the abstraction the programmer controls and tries to summarize and understand. The flowchart is a higher level abstraction of an abstraction.