Flowcharts of programming language constructs

They may only be a hot mess when expressed as a flowchart. But so what? I'm not programming in flowcharts. If exceptions can do what I want cleanly, why do I care if it's a mess considered as a flowchart? That's not my problem.

This argument is like saying that the library function I call is a mess of a flowchart. Why should I care? Can I express what I need to express cleanly by calling that function, or not?

Of all the arguments against exceptions, "it's got a mess of a flowchart" is the absolutely least relevant one.

Programming languages have different "things" built in. Like, if you have re-entrant function calls, then your language has a built-in data structure called "the stack". If you have some algorithm that needs a stack, you have the choice of using the built-in stack, or using an explicit stack.

If you have a programming language with some sort of type system, then you have tagged data built-in. You can model your domain in the type system, or you can model your domain using a tuple like (tag, datablob).

If you have object-oriented programming with dynamic (single) dispatch on the first argument, then your language somewhere has a built-in data structure called a table/dictionary/associative-array. If you want to implement some sort of switching behavior you can do a switch on the `tag`, or encode the tag in the type system, and use dynamic dispatch.

Some programming languages have support for asynchronous calls. That programming language has a built-in scheduler of sorts. You can use it, or build your own, (or use the OS!).

A state machine, I think, is a great example of the same idea. Your CPU has a bunch of state (e.g. the program counter), and your programming languages has a bunch more state (like the current stack frame, the line number). You can encode your state machine in that, or you can model it explicitly. How well you can do it "implicitly" depends on other language features, like whether you have coroutines.

I think it's challenging, without expertise that might come only from having solved an identical problem already, to know ahead of time when to use these built-in things or roll your own. When you mention testing, I think that's a great example of expertise you've acquired. If you would like to test certain invariants in your state machine, e.g. "a transition from A to B never happens", then you're going to have a hard time doing so if your state machine's state is encoded in the line number of your language interpreter or the program counter, or whatever.

In other words, Python requires that model, but making something necessary isn't the same as it being good. If you go around breaking people's arms then splints and casts become necessary. Does that make arm-breaking OK?

> It allows you think about the problem with a much smaller cognitive load.

There's a very fine line between "smaller cognitive load" and "sweeping stuff under the rug". Since you mentioned Python, I'll point out that a lot of Python code only looks simple because it's incomplete and will fail catastrophically for what should be innocuous errors. Add the proper error handling and it's just as complex as code using an error-return or optional-type model. Often that means even more cognitive load because the happy path and the handlers are in multiple methods/classes/files (especially likely as multiple people hack on code over time).