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

51–60 of 88 posts

Re: Flowcharts of programming language constructs

#51

Post by inetknght »

throwaway17_17 wrote: post #40
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.

If you find these flowcharts instructive, and I think that you are well founded in doing so, good on you. A majority of other comments seem to be of the opinion that pointing out the complexity of control flow generated by the constructs in a language is a negative. It certainly seems like the prevailing attitude is ‘if I can’t see it, it doesn’t exist.’ But you said you were working on game code, so I will encourage…

> you said you were working on game code

Actually, I didn't. I said I wanted to "up my game" which is a phrase commonly meaning "to get better". Said another way: I needed to get better at describing code to management.

> I will encourage you to keep thinking about the complexity of the choices you make in which constructs to use

Indeed, management generally wants simpler code even at the cost of performance. Simpler code generally translates to cheaper developers and cheaper maintenance.

> don’t buy into the thought that says performance implications are not a really concern

I actually write DNA analysis software. Performance implications definitely are a concern. :)

But performance is useless if I'm the only developer who understands how it all comes together (eg, high bus factor). So I've been writing a lot of documentation to that end, from file-level down to the systems-level and bit-level descriptions. I really would like better support for diagrams in markdown.

Re: Flowcharts of programming language constructs

#52

Post by LessDmesg »

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…

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

Re: Flowcharts of programming language constructs

#53

Post by AnimalMuppet »

throwaway17_17 wrote: post #38
AnimalMuppet wrote: post #31

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

I'm pretty much never worried about the performance of the "exception taken" case. The compiler can be really quite inefficient there before I have any reason to care.

There are places to worry about compiler efficiency. I don't think that this is one of them.

Re: Flowcharts of programming language constructs

#54

Post by AnimalMuppet »

inetknght wrote: post #28
zabzonk wrote: post #24

Earlier quoted context omitted.

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

To me, that screams "put your resume out on the street".

I mean, I'm not opposed to documentation. It's important. But if your management thinks that flowcharts are the way to do it, I wonder what millennium they think it is.

Re: Flowcharts of programming language constructs

#56

Post by AnimalMuppet »

crimsonalucard wrote: post #27
zabzonk wrote: post #24

Earlier quoted context omitted.

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.

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 drawing or viewing such diagrams. But I agree that 2D flowcharts don't represent parallelism well, and that 3D looks like a better answer.

Re: Flowcharts of programming language constructs

#57

Post by inetknght »

AnimalMuppet wrote: post #54
inetknght wrote: post #28

Earlier quoted context omitted.

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

To me, that screams "put your resume out on the street". I mean, I'm not opposed to documentation. It's important. But if your management thinks that flowcharts are the way to do it, I wonder what millennium they think it is.

Indeed? Flowcharts aren't the only documentation. Swagger describes the API parameters, flowcharts describe the API code flow, and text provides a story, and comments in the code describe particulars.

Flowcharts are just where I've felt that I've significantly underperformed; where management has asked for more of them.

Putting my resume on the street is something I do often. Want to look at it?

If you think flowcharts aren't the way to describe code flow, then I'm curious what method you think is better.

Re: Flowcharts of programming language constructs

#58

Post by AnimalMuppet »

inetknght wrote: post #57
AnimalMuppet wrote: post #54

Earlier quoted context omitted.

To me, that screams "put your resume out on the street". I mean, I'm not opposed to documentation. It's important. But if your management thinks that flowcharts are the way to do it, I wonder what millennium they think it is.

Indeed? Flowcharts aren't the only documentation. Swagger describes the API parameters, flowcharts describe the API code flow, and text provides a story, and comments in the code describe particulars. Flowcharts are just where I've felt that I've significantly underperformed; where management has asked for more of them. Putting my resume on the street is something I do often. Want to look at it? If you think flowchar…

Ah. Flowcharts were all you mentioned, so I assumed (bad move) that they were all you did.

Depending on what exactly you are doing, parts of UML might be better. It lets you describe different aspects with different diagrams, so that, if one kind of diagram is sub-optimal for showing some aspect of what's going on, another kind might be better.

Re: Flowcharts of programming language constructs

#60

Post by tartoran »

DonHopkins wrote: post #50
tartoran wrote: post #45

Earlier quoted context omitted.

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…

Wow, I didn't know about this. Thank you, this is great !!

[0] This is a slightly related vaporware loop which, I don't know, I find it mesmerizing.

[0]: https://invidio.us/watch?v=-RFunvF0mDw

Post reply on HN