Flowcharts of programming language constructs
progsbase.com
Flowcharts of programming language constructs
1–10 of 88 posts
Re: Flowcharts of programming language constructs
#2A brilliant explanation of why no-one uses flowcharts.
Re: Flowcharts of programming language constructs
#3Pretty neat. Three things that occurred to me while reading it.
(1) Makes it pretty clear why exceptions are even more of a control-flow nightmare than goto. What a messy graph.
(2) The 'defer' diagram is a big WTF. Couldn't even figure out which box is supposed to represent which statement in the example.
(3) I'd love to see a graph of the control flow when you throw in a few spurious lambdas like "advanced" C++ programmers tend to do (and similar in a few other languages). Might even make exceptions look good.
Re: Flowcharts of programming language constructs
#4A brilliant explanation of why no-one uses flowcharts.
...because if they did, they might realize that some of their favorite structures are a hot mess. Seeing things in a new way often leads to learning, which a good developer would welcome. Personally I can't remember the last time I used an actual flowchart, but I do use state machines. Sometimes I'll go through an exercise of re-casting complex logic as a state machine. Often, that leads to a realization that making the state machine explicit would yield far more testable and maintainable code than leaving it in its more common if/loop/nested-function form.
Re: Flowcharts of programming language constructs
#5A brilliant explanation of why no-one uses flowcharts.
They can be useful though, like once in a blue moon on a white boarding session with non-technical users, explaining a bug or something like that
Re: Flowcharts of programming language constructs
#6Pretty neat. Three things that occurred to me while reading it. (1) Makes it pretty clear why exceptions are even more of a control-flow nightmare than goto. What a messy graph. (2) The 'defer' diagram is a big WTF. Couldn't even figure out which box is supposed to represent which statement in the example. (3) I'd love to see a graph of the control flow when you throw in a few spurious lambdas like "advanced" C++ pro…
Exception is a nightmare only if you use it as a general purpose control flow mechanism.
Re: Flowcharts of programming language constructs
#7Pretty neat. Three things that occurred to me while reading it. (1) Makes it pretty clear why exceptions are even more of a control-flow nightmare than goto. What a messy graph. (2) The 'defer' diagram is a big WTF. Couldn't even figure out which box is supposed to represent which statement in the example. (3) I'd love to see a graph of the control flow when you throw in a few spurious lambdas like "advanced" C++ pro…
Exception is a nightmare only if you use it as a general purpose control flow mechanism.
Unfortunately, many do. When that includes popular libraries and frameworks, "abuse" becomes idiomatic or even strictly necessary. When it's in the language itself, such as Python's use of KeyError or StopIteration, that's even more true. Since better alternatives exist for most exception use cases, I'm of the opinion that direct language support was a bad idea. A more general and explicit cousin of signal handlers would suffice for those few "stop the world" cases, and can be done via library functions. Optional types, multiple return values, or plain old error codes (I like Zig's "non-ignorable error code" approach) suffice for the rest.
Re: Flowcharts of programming language constructs
#8A brilliant explanation of why no-one uses flowcharts.
...because if they did, they might realize that some of their favorite structures are a hot mess. Seeing things in a new way often leads to learning, which a good developer would welcome. Personally I can't remember the last time I used an actual flowchart, but I do use state machines. Sometimes I'll go through an exercise of re-casting complex logic as a state machine. Often, that leads to a realization that making…
>they might realize that some of their favorite structures are a hot mess
Normal brain: Find the representation that best expresses the structure to discover the hidden simplicity in everything.
Galaxy brain: Use flowcharts to draw out how exceptions work, forget your previous understanding, and then realize that they are too complicated for anyone to use.
Re: Flowcharts of programming language constructs
#9A brilliant explanation of why no-one uses flowcharts.
...because if they did, they might realize that some of their favorite structures are a hot mess. Seeing things in a new way often leads to learning, which a good developer would welcome. Personally I can't remember the last time I used an actual flowchart, but I do use state machines. Sometimes I'll go through an exercise of re-casting complex logic as a state machine. Often, that leads to a realization that making…
Exceptions are rather easy to reason in the code but their flow chart looks like a hot mess. So your argument is invalid?
Re: Flowcharts of programming language constructs
#10The C-style switch/case construct is obsolete and awkward, and cleaner alternatives exist, such as VB.net's technique. There is no need for "Break".
The following could be added to C-style languages without overlapping with the existing syntax:
select(a) {
when 1,2,3 {...}
when 4 {...}
when 5,6 {...}
...
otherwise {...}
}