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

21–30 of 88 posts

Re: Flowcharts of programming language constructs

#21

Post by TFortunato »

lwb wrote: post #12

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.

LongJmp can be used as a way to implement exceptions at a low level, especially in languages like C, where you dont have them as a language construct.

You call SetJmp, where you would want to put your try/catch blocks, then no matter how deep down some call stack you go, if an errir occurs, you can immediately jump back to where you called setjmp and handle it / report the error or whatever, rather than having to handle and bubble up the error by at every intermediate level, "returning" your way up the call stack.

Re: Flowcharts of programming language constructs

#22

Post by carapace »

gnulinux wrote: post #9
notacoward wrote: post #4

Earlier quoted context omitted.

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

> Exceptions are rather easy to reason in the code

In some code, for some people.

> their flow chart looks like a hot mess

In code where the "exceptions are rather easy to reason" about the flowchart would also be easy to read.

In code where the exceptions hide a flowchart that's a hot mess the exception syntactic sugar hides the mess.

Re: Flowcharts of programming language constructs

#23

Post by keithb- »

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 agree. The semantics even within this set of flowcharts is confusing: blocks start out representing statements but by the time you get to Dependency Injection, they represent anything (library, service, etc.). Also the dotted-line vs solid line doesn't help. With Goto or Exception, the dotted line is the process, not the alternative which is solid. Those need to be inverted because "normal" flow of control from statement to statement is altered and the "exceptional" flow is now active and other statements are ignored. Just waiting for someone to say "we tried this with UML already. please just stop."

Re: Flowcharts of programming language constructs

#24

Post by zabzonk »

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.

Re: Flowcharts of programming language constructs

#25

Post by airstrike »

carapace wrote: post #22
gnulinux wrote: post #9

Earlier quoted context omitted.

Exceptions are rather easy to reason in the code but their flow chart looks like a hot mess. So your argument is invalid?

> Exceptions are rather easy to reason in the code In some code, for some people. > their flow chart looks like a hot mess In code where the "exceptions are rather easy to reason" about the flowchart would also be easy to read. In code where the exceptions hide a flowchart that's a hot mess the exception syntactic sugar hides the mess.

One could argue hiding the mess is the whole point of the exception. It allows you think about the problem with a much smaller cognitive load.

I'm not suggesting every code with exceptions is good. Just saying that not every exception is bad, and many are indeed great.

I can't imagine writing Python without try blocks...

Re: Flowcharts of programming language constructs

#27

Post by crimsonalucard »

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.

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.

Re: Flowcharts of programming language constructs

#28

Post by inetknght »

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.

I quite agree. Unfortunately management wants single-threaded code and wants it documented with flowcharts. So right now there's lots (!) of clouds detailing "this calls into another API documented in another flowchart..."

Re: Flowcharts of programming language constructs

#29

Post by tabtab »

nneonneo wrote: post #15
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…

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 required, then it's superfluous: code-bloating eye clutter. If you never used a language that didn't need "Break" you may not understand how annoying it is to go back.

My suggestion above allows C-ish languages to add a modernized version and yet keep the existing construct for backward compatibility. In other words, the old one would be "deprecated".

Re: Flowcharts of programming language constructs

#30

Post by raslah »

I actually really like flowcharts, though they are somewhat inefficient to draw out more complex structures, they are great for working out small sections of thorny logic. The only issue I sort of take those in the article is the physical flow is a little distracting when decisions don't branch laterally. having them continue top to bottom sort of throws me off. perhaps its just because i draw them with branches to the side.
Post reply on HN