What did the author use to make the charts?
Flowcharts of programming language constructs
61–70 of 88 posts
Re: Flowcharts of programming language constructs
#62Pretty 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…
My impression was that the article made the exceptions graph much more complicated than it needed to be. Each function doesn’t need three boxes, and they don’t need to each throw exceptions twice. IMO exceptions are much cleaner in practice and are great for things like “kill this script” or “throw a 500 error”.
Actually the exceptions graph is simplified. The code to perform unwinding is not depicted.
Re: Flowcharts of programming language constructs
#63Pretty 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…
(1) There's nothing messy about that graph. It's just two nested function calls. An exception by itself is just a goto to the catch block.
yep, the goto example is doing something completely different and less than the exception code, of course it will look more messy.
Re: Flowcharts of programming language constructs
#64Re: Flowcharts of programming language constructs
#65Speaking of reasoning, I believe a Hoare proof of correctness for a flowchart is
* a choice of a precondition and postcondition, Pre(B) and Post(B), for every basic block B
* for every basic block B, a proof that {Pre(B)} B {Post(B)}
* for every arrow a : B1 -> B2, a proof that Post(B1) /\ Cond => Pre(B2) where Cond is the condition for the arrow to be taken
Re: Flowcharts of programming language constructs
#66I think flow charts are a lot more useful when the granularity is more coarse: the boxes should represent functions, not the logic inside.
compute thing -> predicate true ------> compute some other thing
| -> predicate false ->|
\---------------loop-----------/
Re: Flowcharts of programming language constructs
#67What did the author use to make the charts?
I used "yEd live".
Re: Flowcharts of programming language constructs
#68Earlier quoted context omitted.
> ...because if they did, they might realize that some of their favorite structures are a hot mess. 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…
The flow charts in the link represent control flow. Compiler optimizations are, in part, constrained by their ability to map and statically determine control flow. So I think it is a grave mistake to say that something having a ‘mess of a flowchart’ is the least relevant concern about some PL construct. The implication that a flowchart representation offers nothing to a programmer, implies that the performance charac…
Statically determining data flow is just as important, since it means being able to parallelize your code. Flowcharts are a very limited tool, other diagramming approaches (such as proof nets) can generalize on them in a helpful way.
Re: Flowcharts of programming language constructs
#69Pretty 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…
My takeaway was the exact opposite of yours. For example the goto graph seems very intuitive and simple. But it is much more complex to reason about compared to exceptions. My takeaway was that simple graphs like these can't really explain the pros and cons of high level programming constructs.
It's even clearer when you consider higher-order functions. These diagrams are only able to represent functions of order at most 2, i.e. what is called "dependency injection".
Re: Flowcharts of programming language constructs
#70Earlier quoted context omitted.
Except when they're not.
Don't blindly repeat what Go fans say, it's useful to use own head sometimes.
What are you even talking about? Are you replying to the wrong post? I don't even know how to play Go. I prefer Othello. It's simple and convenient. Anyway, didn't Dijkstra write a paper warning "Go Considered Harmful"?