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
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.
>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.
>Are you confused about the meaning of understanding vs a literal equivalence?
No, but you seem to be about any context not spelled out completely and pedantically.
>e.g. “ Because the code is the entirety of the process” is clearly false regardless of which way you look at it.
A coder works on code (literally editing lines of code, which is what they deliver), and is called to create, understand, and debug code.
Else, sure, code also runs on some server, by some organization, that had meetings to decide the requirements, and there are also end users, and the whole thing runs in some planet, inside a universe, or perhaps a multi-verse, so the code its not the entirety of the process /s
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?
Having an "e" pronounced "a" in french is very rare, I would also intuitively only expect it to happen when the "e" is followed by two consonants.
A french person would likely mispronounce scheme either as "shem" or "skem", based on their familiarity with english. We have "Schéma" for "schematics", and we pronounce it "shem-a"
I believe what you're looking for is Jq for the json prettifying/manipulation, and nushell for tabular text (not sure about that one, I've only seen it mentioned occasionally).
I strongly believe this should not become the job of the terminal, as it makes it all the more complicated and would possibly deter people from writing the kind of specialized, portable tools that are Jq and nushell for instance.
At most, I think it should be a job for an ncurses application
Everyone is free to not use this feature when it eventually implemented in terminals. Just like syntax highlighting, code completion and AI copilots.
The thing is that as a heavy user I do use jq, terminal triggers and my own stdout colouring/parsing apps that e.g. highlight and parse timestamps or numbers. It all kinda works via endless Cmd+C, "pbpaste | jq" etc but it feels wasteful.
I want to interact with what terminal shows me, not just look at it and copy/paste with broken formatting to somewhere else.