Live data from Hacker News

Flowcharts of programming language constructs

progsbase.com

41–50 of 88 posts

Re: Flowcharts of programming language constructs

#41
This is a wonderful idea, but by the given numbering scheme, I can identify a slew of problems.

[1a. If] Note This is the first time we see synchronous calls, decisioning, and the representation makes no specific callout to the structure. The structure IS the case.

[4. Break] InconsistencyConfusion This is the first time we see a specific part of the flow called out as the structure (it isn't a structure). This is flow control, not a construct. This confusion plagues the rest of the document.

[7. Switch (No Fall-Through)] InconsistencyConfusion This is the same as If/elseif.../else/, but the post goes with the oddly specific "switch". Would be more appropriate as [1c. if/elseif.../else] and a [1d. Switch] - The different terminology if/switch does not change the fact they are the same structure. Grouping Switch-type by name is a bad choice.

[9. Local Goto] Omission The Goto example has no exit node.

[11. Exceptions] Mistake The exception travels the stack, meaning (from the perspective of the original parent function), from grandchild to the child, to the parent catch.

[12. Finally] OmissionConfusion Finally should be it's own block, since it is treated as such and has an implicit catch mechanism, even if it's not always required in the syntax.

[13. Blocking, Synchronous Calls] Confusion This is rather pointless. All the flows, prior, were blocking. Now introducing another metaphor that changes past examples is inconsistent. Blocks which are synchronous (blocking) are represented by 2 different forms. It's unnecessary.

[14a. Non-Blocking, Asynchronous Call, Callback] InconsistencyConfusion There is a whole function called, which should be represented by a starting and ending node.

[14b. Device Input] InconsistencyConfusion This isn't even a different construct. Event handling is what this is and is poorly represented, in the same way as 14a.

[15. Framework] MistakeConfusion This isn't a construct, nor is it an accurate representation. Frameworks are a collection of idioms, which usually has little to do with constructs (as defined in the beginning). It feels like the author has gone off the rails here.

[18 Come-from & 19 Aspects & 21 Destructor] Confusion? The size of the block is supposed to indicate a specific syntax, which is inappropriate for describing logical constructs. They should be full sized and optionally labeled blocks, as they are evaluated.

[20 Dependency Injection] Confusion This is another "timing adds a new way to represent things" issue. There's no difference between an Aspect and DI, logically.

[22. Defer] *Confusion Adding data (even a function) to a separate stack, which is called later, does not make the diagram presented.

All in all, this needs work. Even the grouping description at the bottom does nothing to help make this more useful.

Re: Flowcharts of programming language constructs

#42

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…

There's actually a fairly natural way of representing Result-like types (including exceptions) in a flow chart. Draw multiple "exit" terminals for the function, one for "success" and one for each error case. Then a function invocation can have multiple flowlines leading from it, one for each case. And one can "rethrow" the exception quite naturally, by having a flowline for a "rethrown" exception lead to an exit terminal of its own. This also applies by analogy to the case of multiple entry terminals, which come up most naturally when desugaring async functions.

(It's actually even simpler than that when accounting for the functor and monad properties of Result, but the graphical representation for a "functor" or "monad" is a bit more complex; these would be drawn as labeled regions, and functor and monad properties would describe how such regions can be "merged" or "combined".)

Re: Flowcharts of programming language constructs

#43

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…

RE (2): Defer. The diagram has an extra box in the control flow which is unnecessary. You can label the big boxes from top to bottom like so: A E B D C.

A good use case for understanding the control flow of 'defer' is when cleaning up resources.

    mutex.lock();
    defer { mutex.unlock(); }

    val f = File.open(filename);
    defer { f.close(); }

    // write to file
It's a nice construct because it keeps construction and destruction close together instead of far apart

    mutex.lock();
    val f = File.open(filename);

    // write to file

    f.close();
    mutex.unlock();

Re: Flowcharts of programming language constructs

#44
The Nassi-Shneiderman diagram is one way of representing structured program flow by dividing up a two-dimensional area. It can't represent unstructured gotos and exceptions, though.

https://en.wikipedia.org/wiki/Nassi%E2%80%93Shneiderman_diag...

>A Nassi–Shneiderman diagram (NSD) in computer programming is a graphical design representation for structured programming. This type of diagram was developed in 1972 by Isaac Nassi and Ben Shneiderman who were both graduate students at Stony Brook University. These diagrams are also called structograms, as they show a program's structures.

>Overview: Following a top-down design, the problem at hand is reduced into smaller and smaller subproblems, until only simple statements and control flow constructs remain. Nassi–Shneiderman diagrams reflect this top-down decomposition in a straightforward way, using nested boxes to represent subproblems. Consistent with the philosophy of structured programming, Nassi–Shneiderman diagrams have no representation for a GOTO statement.

>Nassi–Shneiderman diagrams are only rarely used for formal programming. Their abstraction level is close to structured program code and modifications require the whole diagram to be redrawn, but graphic editors removed that limitation. They clarify algorithms and high-level designs, which make them useful in teaching. They were included in Microsoft Visio and dozens of other software tools, such as the German EasyCode.

>In Germany, Nassi–Shneiderman diagrams were standardised in 1985 as DIN 66261. They are still used in German introductions to programming, for example Böttcher and Kneißl's introduction to C, Baeumle-Courth and Schmidt's introduction to C and Kirch's introduction to C#.

>Nassi–Shneiderman diagrams can also be used in technical writing.

When Ben Shneiderman and Ike Nassi (who were grad students at the time) submitted their paper about them to Communications of the ACM, it was quickly rejected on October 4, 1972, with the most brutal rejection letter Ben Shneiderman has ever received.

But then they submitted it to the unrefereed ACM SIGPLAN, where it was published in August 1973, and since then it has been cited many times, widely implemented by many tools, and used for educational and documentation purposes. It's a great example of the importance of persistence for people whose new ideas are brutally rejected by respected authorities:

Flowchart techniques for structured programming:

https://dl.acm.org/doi/10.1145/953349.953350

Scan of the brutal referee's report:

https://www.cs.umd.edu/hcil/members/bshneiderman/nsd/rejecti...

>My first thought was to write a referees report which would by its sarcastic nature be funny. For example, I thought of writing that it was a sound, useful theory, but it wasn't practical because it would be difficult to design flowcharting templates to be manufactured and sold.

>I guess, however, that it is best to come right out and say that I feel the best thing the authors could do is collect all copies of this technical report and burn them, before anybody reads them. My opinion is that it shows the inexperience and ignorance of the authors with respect to programming in general, and their misunderstanding of so-called structured programming.

>To say that [BEGIN body END] should be written as [NS diagram] is ridiculous. Even more ridiculous is having to write [DO i=1 TO N; DO J=1 TO N; S = 0; DO K=1 TO N; S=S+A(I,K)*B(K,J) END C(I,J)=S END END] as [NS diagram].

>The authors mention that "the ease with which a structured flow-chart can be translated into a structured program is pleasantly surprising". My retort is "yes, just erase those silly boxes!"

>Flowcharts are a crutch we have invented to try to understand programs written in a confusing style. This was due to our ignorance of the programming process and what was needed -- after all, programming is only 20-30 years old. So-called "structured programming" helps to limit us to, as Dijkstra calls them, "intellectually manageable" programs, in which case flowcharts are completely useless and in fact a hindrance to programming. They shouldn't be used.

>I shudder at the thought of further explorations revolving around the context-free nature of this [flowchart] language.

Ben's rejection letter story:

https://www.cs.umd.edu/hcil/members/bshneiderman/nsd/rejecti...

>Rejection letter from the Communications of the ACM

>Ben Shneiderman, June 12, 2003

>Our submission of the structured flowcharts to the Communications of the ACM was quickly rejected, on October 4, 1972, by the Programming Languages Editor David Gries of Cornell University. He included a single anonymous reference letter which is on paper that has a Cornell University watermark. I assume Gries gave our paper to one of his colleagues (you can play the guessing game too), who wrote the most brutal rejection letter I have ever gotten.

>The reviewer wrote: "I feel that the best thing the authors could do is collect all copies of this technical report and burn them, before anybody reads them." As graduate students, this stinging rejection shocked us, but we kept getting enthusiastic responses from people around us. We sent the paper to the unrefereed ACM SIGPLAN Notices, where it was published in August 1973. It didn't take long for others to produce extensions, software tools, and applications of structured flowcharts.

>The next problem was theft of the idea. I had sent a draft to respected colleagues, and soon others published slight variations. One of these respected colleagues was Ned Chapin, who greatly troubled us by publishing what he called 'Chapin Charts.' A friend of mine sent me his published paper with a note encouraging me to sue. For several years I feared that Chapin's reputation and his frequent professional seminars would wind up leaving the idea tied to his name, but as the decades passed, the ending has proved to be a happy one. We called the idea 'structured flowcharts, but they are widely known as Nassi-Shneiderman Diagrams.

>Another problem was the appearances of patents for variations on our idea, but these have not limited the widespread recognition we have gotten over the years.

>I wish every graduate student or young inventor would have the pleasure of seeing his/her ideas spread so far and influence the work of so many people. I also hope that the story of the bold rejection of our novel idea and its eventual international success, is an inspiration for anyone whose new ideas are rejected by some respected authorities.

More on Ben Shneiderman and NS diagrams:

https://news.ycombinator.com/item?id=11368430

https://news.ycombinator.com/item?id=11370099

https://news.ycombinator.com/item?id=22093072

Re: Flowcharts of programming language constructs

#45
post #5

Earlier quoted context omitted.

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

They're great for compressing lyrics! Rick Flow: https://pbs.twimg.com/media/DHnyCwiXsAAFyzq.jpg Circumstances In Which Whipping It May Be Appropriate: https://gypsywitchcampfire.files.wordpress.com/2015/08/whip-... Total Eclipse of the Heart: https://i.pinimg.com/originals/86/17/e8/8617e878f9c33ab3a3ba... We Will Rock You: https://www.edrawsoft.com/template/lyric-flowchart.png Let It Be: https://i.pinimg.com/origina…

Yes, this is a great use. I wonder if there's any tool to automate this.

I just gave Modern Love a listen, thanks, this was great.

Re: Flowcharts of programming language constructs

#46

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…

Hi, I am the author of the article, thanks for noting an error in the exception and finally diagrams! I have fixed the error where controlflow always went to the catch block.

Re: Flowcharts of programming language constructs

#47
post #14

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.

It all boils down to "flaggy code" -vs- "spaghetti code" (or vexillology -vs- pastafarianism).

https://wiki.c2.com/?GoTo

Re: Flowcharts of programming language constructs

#48

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

Except when they're not.

Re: Flowcharts of programming language constructs

#50

Earlier quoted context omitted.

They're great for compressing lyrics! Rick Flow: https://pbs.twimg.com/media/DHnyCwiXsAAFyzq.jpg Circumstances In Which Whipping It May Be Appropriate: https://gypsywitchcampfire.files.wordpress.com/2015/08/whip-... Total Eclipse of the Heart: https://i.pinimg.com/originals/86/17/e8/8617e878f9c33ab3a3ba... We Will Rock You: https://www.edrawsoft.com/template/lyric-flowchart.png Let It Be: https://i.pinimg.com/origina…

Yes, this is a great use. I wonder if there's any tool to automate this. I just gave Modern Love a listen, thanks, this was great.

Paul Lamere from The Echo Nest made an awesome music analysis demo called "The Infinite Jukebox" (for when your favorite song just isn't long enough), for automatically finding loopable points in music. And it can use that analysis to stretch a song out to any duration you want, by seamlessly skipping and looping parts of it to shorten or stretch it. It's interactive, so you can point and click on the arcs to control how it loops at any point.

https://en.wikipedia.org/wiki/The_Echo_Nest

http://infinitejukebox.playlistmachinery.com/

Infinite Jukebox

For when your favorite song just isn't long enough

This web app lets you upload a favorite MP3 and will then generate a never-ending and ever changing version of the song. Infinite Jukebox uses the Echo Nest analyzer to break the song into beats. It plays the song beat by beat, but at every beat there's a chance that it will jump to a different part of song that happens to sound very similar to the current beat. For beat similarity the uses pitch, timbre, loudness, duration and the position of the beat within a bar. There's a nifty visualization that shows all the possible transitions that can occur at any beat. Built at Music Hack Day Boston 2012.

Billie Jean Forever:

http://infinitejukebox.playlistmachinery.com/?trid=TRSFLTX13...

Scatman (Ski-Ba-Bop-Ba-Dop-Bop) by Scatman John:

http://infinitejukebox.playlistmachinery.com/?trid=TRXKEZN13...

Lots more cool Echo Nest demos:

http://static.echonest.com/labs/

http://static.echonest.com/labs/demo.html

Post reply on HN