Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Flowcharts of programming language constructs

progsbase.com

Post reply on HN
Print view View original

71–80 of 88 posts

Re: Flowcharts of programming language constructs

#71

Post by zozbot234 »

AnimalMuppet wrote: post #56
crimsonalucard wrote: post #27

Earlier quoted context omitted.

This is because flow charts are two dimensional. What you need is a 3rd dimension to represent parallelism. These programs are better represented as 3d structures rather then 2d flow charts or even text.

3D. I like it. I think I agree. The closest I've seen to anything that actually does that is UML. But it does so only by having multiple different diagrams. That's like having a drawing with a front view and a side view - it's not a 3D diagram, it's two 2D diagrams that you can use to kind of see what's going on in 3D. I don't know of any good system of notation that does what you're asking, nor any software for draw…

UML is non-rigorous and has a whole lot of pointless incidental complexity. Intuitive representations of parallelism are fairly natural in data flow, but that is precisely dual to flowcharts; you can not represent both on the same 2D diagram without some very precise rules about what portions of the diagram are intended to represent each. Proof nets give you something not unlike this.

Re: Flowcharts of programming language constructs

#72

Post by beetwenty »

bibyte wrote: post #32
notacoward wrote: post #3

Pretty 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.

The tradeoff in goto-vs-exception is that a goto needs an explicit label, while an exception allows the destination to be unnamed, constrained only by the callstack at the site where it's raised.

That makes exceptions fall more towards the "easy-to-write, hard-to-read" side of things; implied side-effects make your code slim in the present, treacherous as combinatorial elements increase. With error codes you pay a linear cost for every error, which implicitly discourages letting things get out of hand, but adds a hard restriction on flow. With goto, because so little is assumed, there are costs both ways: boilerplate to specify the destination, and unconstrained possibilities for flow.

Jumping backwards is the primary sin associated with goto, since it immediately makes the code's past and future behaviors interdependent. There are definitely cases where exceptions feel necessary, but I believe most uses could be replaced with a "only jump forward" restricted goto.

Re: Flowcharts of programming language constructs

#73

Post by tel »

notacoward wrote: post #3

Pretty 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…

This sort of formalism is bad for handling multiple returns and thus exceptions. For instance, they become very simple in continuation passing style whereas GOTO is difficult.

Flowcharts feel like a simple and universal way of talking about, well, control flow, but they imply a certain kind of bias toward a kind of reasoning which isn't necessarily all that better than code itself.

Re: Flowcharts of programming language constructs

#74

Post by anigbrowl »

tartoran wrote: post #5
zabzonk wrote: post #2

A 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

You can use them for just about anything once you get used to the idea of dynamic nesting. I'm particularly fond of this implementation:

http://www.dsprobotics.com/applications.html

Re: Flowcharts of programming language constructs

#75

Post by anigbrowl »

zabzonk wrote: post #24
inetknght wrote: post #13

As someone who's self-taught everything, this is... awesome. It's exactly what I needed to be able to up my game in describing code to management using the flowcharts they've asked for.

In case you haven't gleaned it from the majority of comments here, flowcharts are a terrible way to describe code, particularly modern, multi-threaded code that uses exceptions. Don't go there.

Obviously you don't like them, but flow based programming is pretty great actually.

Re: Flowcharts of programming language constructs

#76

Post by lwb »

edflsafoiewq wrote: post #62
lwb wrote: post #11

Earlier quoted context omitted.

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.

The graph isn’t about implementations — it also doesn’t show that you have to increment a counter to make a loop.

Re: Flowcharts of programming language constructs

#77

Post by 0xff00ffee »

Raise your hand if you at first thoroughly expected to mock this, and then giggled at "function" (vs. subroutine), patted yourself on the back for knowing everything up until ... ASPECT? DAFUQ IS ASPECT?

Just me? Ok, I'll show myself out.

Great way to visualize. I think Exceptions, Finally (and Promises) got a little messy, but would make a good poster.

Re: Flowcharts of programming language constructs

#78

Post by int_19h »

tabtab wrote: post #29
nneonneo wrote: post #15

Earlier quoted context omitted.

GCC has had case ranges as an extension for a long time now: https://gcc.gnu.org/onlinedocs/gcc/Case-Ranges.html It’s a far cry from general pattern matching (a la Rust, Scheme) but it’s helpful in some circumstances. Otherwise, you can also stick multiple case labels together, i.e. switch(x) { case 1 ... 4: case 7: case 9 ... 16: ... default: ... } I don’t see why you need to call the C-style construct obsolete and…

Ranges are nice, but not a replacement for sets. (Allow both!) The main "fix" I propose is to get rid of the Break statement and the very need for it. If you have set-based lists, you don't need "fall through" behavior because you can have more than one item per matching expression. The Break statement is error prone because it's easy to forgot. Some languages "solved" that by making Break required; but if it's requi…

> If you have set-based lists, you don't need "fall through" behavior because you can have more than one item per matching expression.

This is not entirely true. Ranges and sets allow you to run the same code for different inputs. Fallthrough allows you to run partially the same code for different inputs.

It's a rare case, so I don't think its utility warrants making fallthrough behavior the default. But it's nice to have it explicitly, like "goto case" in C#.

Anyway, the reason why it is the way it is in C, is because case labels are literally labels, and the switch statement itself is just a branched goto - which is why e.g. Duff's Device is a thing. And that, in turn, is probably because it's a descendant of "switch" in Algol-60, which was basically an array of labels.

Re: Flowcharts of programming language constructs

#80

Post by quelltext »

0xff00ffee wrote: post #77

Raise your hand if you at first thoroughly expected to mock this, and then giggled at "function" (vs. subroutine), patted yourself on the back for knowing everything up until ... ASPECT? DAFUQ IS ASPECT? Just me? Ok, I'll show myself out. Great way to visualize. I think Exceptions, Finally (and Promises) got a little messy, but would make a good poster.

I'm sure you're not the only one, but yes AOP is something a lot of people interested in programming languages have likely heard of at some point.
Post reply on HN