- Properly formatted high-level language code (with your editor adding coloration and such) is almost as (or more) readable than a flowchart. Flowcharts were OK when your code had to be written with “GOTO”, but not so much with clear conditional and looping constructs.
- Programs got much larger. You can flowchart a fundamental algorithm, or a small program like Blink, pretty easily, but it falls apart once your flowchart would exceed a single viewable page. You can do High Level flowcharts, but they're not obviously better than pseudo-code or a clear human-language description.
- They aren't very good at depicting popular modern programming concepts like recursion or objects.
- They somewhat date back to times when "programming" was separate from "coding" - some scientist or MBA would describe what they wanted to do with a flowchart, and hand it off to someone who took that mail-order COBOL or ForTran class for actual conversion to code.
- And yeah, compilers got faster, and environments more interactive, and editors better, and men learned to type, and ... People don't PLAN out their programs as much in advance as was "necessary" back when you'd hand your flowchart to a coder, who'd fill in a "coding sheet" that was handed off to keypunch operator, who in turn would queue the card deck for the Computer Operator to feed into the mainframe, which would do stuff with the code at $1000/CPU-minute charged to your department, finally giving your results in a day or two...
1 Like
- Years past the rule was to have a flow chart for each task.
- I don’t use flow charts that often now.
When I do it’s as a teaching aid.
In the beginning, most new users seem to benefit from a picture versus looking at code.
- Now use MS Word when there is a need.
FlowCharts Using MS Word.pdf (358.8 KB)
2 Likes
Today, flowcharts are still used in some niches, like teaching basic logic, explaining business processes, or documenting complex control flows, but they’re often replaced by pseudocode, UML diagrams, state machines, and visual tools built into IDEs.
In the 1960s–80s, they were common because programming was less standardized, documentation was mostly on paper, and visual planning helped structure algorithms before coding - useful as well because compilation was a heavy process - sometimes you would only get one attempt a day (during the night as a delayed job) as the computer was used during the day for production.
Also Agile methods and rapid prototyping with « instant compiler » also encouraged iterating directly in code rather than designing extensive flowcharts first.
2 Likes
Thanks for the thoughts.
I'm thinking about how to write some code for something I'm working on and in my head is a switch / case based state machine. Since starting this topic I realise switch / case is my flowchart.
1 Like
More posts ask for a finite state machine and therefore a state diagram is better suited than a flow diagram.
3 Likes
Yes - the typical graphical representation of a state machine is a state diagram, where each state is shown as a labeled circle or rounded rectangle, and transitions between states are shown as arrows labeled with the event or condition that triggers the change.
1 Like
The state machine course I did learned to show each state as a circle (in practice a blob) in which every state itself was a micro state machine consisting of ``{STATE_ENTER, STATE, STATE_EXIT }``.
The STATE_ENTER held the code that should be executed (only) when entering from another state, the STATE_EXIT held the code that should be executed when exiting to another state.
A typical examples are the malloc() and free() of dynamic arrays only used in that state, do some one time math, the flushing of IO or display buffers, clean up, etc.