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

11–20 of 88 posts

Re: Flowcharts of programming language constructs

#11

Post by lwb »

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

Re: Flowcharts of programming language constructs

#12

Post by lwb »

The point this article makes most clear is exactly to what extent C++ has the attitude of “screw it, let’s put it in”. There are only a handful of constructs listed that C++ doesn’t implement.

Also, TIL about “long jump”. Seems like a feature I’d never use in a million years, but maybe it has its applications.

Re: Flowcharts of programming language constructs

#14

Post by ken »

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…

If you think exceptions look messy as a flow chart, try conditions! It’s be like exceptions x come-from.

And yet in practice, it’s really not that confusing. Expressivity counts for more than the number of branch opcodes generated by the compiler.

Re: Flowcharts of programming language constructs

#15

Post by nneonneo »

tabtab wrote: post #10

The 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 {...} } C# recently added a pattern-matching alternative, but it's still a bit verbose for most needs.

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 awkward, though. It works plenty well for enumerations, which is basically what it was designed for. If you need to do something more fancy, if/else if chains always work.

Re: Flowcharts of programming language constructs

#18

Post by avodonosov »

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…

exceptions are simple and convenient

Re: Flowcharts of programming language constructs

#19

Post by MadWombat »

I don't know about everyone else, but to me these are confusing as fuck. In continue/break/early return diagrams, there is no second condition, so it is not clear when/why the dotted line logic path happens. The "no fall-through" has so many arrows it takes some zen meditation to figure out what it means. And the exception diagram is just amazing, does the catch block get executed no matter whether there was an exception or not? Because there is an arrow leading to it from the regular, no exception, path. I could go on, but it becomes progressively more and more bizarre.

Re: Flowcharts of programming language constructs

#20

Post by grawprog »

MadWombat wrote: post #19

I don't know about everyone else, but to me these are confusing as fuck. In continue/break/early return diagrams, there is no second condition, so it is not clear when/why the dotted line logic path happens. The "no fall-through" has so many arrows it takes some zen meditation to figure out what it means. And the exception diagram is just amazing, does the catch block get executed no matter whether there was an excep…

>I don't know about everyone else, but to me these are confusing as fuck.

I was alright right up until it got to exceptions. Simple statements are fairly nicely represented in flowchart form and almost condense the information a bit. Then it hits exceptions and everything after that just got so convoluted it became pretty ridiculous. Imagine trying to write out even 100 lines of modern code like that. You'd need a page the size of the side of a barn just for that.

Post reply on HN