Pretty neat, but notably missing some of the more functional control flow concepts: tail calls, call with current continuation, delimited continuation, etc.
Flowcharts of programming language constructs
81–88 of 88 posts
Re: Flowcharts of programming language constructs
#82Raise 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.
The actual question is : did it allow you to quickly understand the "aspect" concept by using a common graphical representation? If yes, that's a win
Re: Flowcharts of programming language constructs
#83Pretty 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…
> (2) The 'defer' diagram is a big WTF. Couldn't even figure out which box is supposed to represent which statement in the example.
I found the defer diagram very accurate and understandable, but I already knew what "defer" does.
From the preceding examples, I understand that the little box is an instruction the developer didn't write, but was added automatically. From the graph, I understand that the instructions are executed in a different order from what it's written by the developer (and exactly in reverse order).
Re: Flowcharts of programming language constructs
#84Raise 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.
[deleted]
Re: Flowcharts of programming language constructs
#85Raise 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.
The actual question is : did it allow you to quickly understand the "aspect" concept by using a common graphical representation? If yes, that's a win
No. The explanation isn't clear: why is g() inserted at one point and h() inserted at another. This needs to be explained.
However, from what I observe, "aspects" look a lot like Common LISP Object System (CLOS) before/after/around methods.
Re: Flowcharts of programming language constructs
#86Earlier quoted context omitted.
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.
Oh, I never said UML was ideal. I merely said that, if you squint, you could see it as a clumsy, inadequate, and probably unintentional half-step in the direction of crimsonalucard's idea.
Re: Flowcharts of programming language constructs
#87Earlier quoted context omitted.
> 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...
Describing the mess in a not-messy way is the whole point of exceptions. If you have a mess in your code either clean it up or document it, don't hide it.
- - - -
Sometimes the problem you're solving really does require a gnarly flow-chart. If that's the case, you're almost certainly better off writing (and documenting!) a state machine instead.
If your control-flow graph is only a little gnarly then representing it with exception syntax is fine IMO (I write Python code too, with exceptions.)
The problem comes when you accidentally create a hidden gnarly graph (as the result of bad design up front, or "drift" over time as a piece of code gets reworked, maybe by multiple people who may not all be privy to the whole history of the design and code, or both) and then forget to do something crucial along some flow of control and you have a hard-to-debug bug.
Re: Flowcharts of programming language constructs
#88Earlier quoted context omitted.
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…
> Fallthrough allows you to run partially the same code for different inputs.
True, but it's a screwy way to manage such overlaps. The volume of errors and confusion exceeds the benefits in my opinion. There are other ways to do such. For non-trivial conditionals (such as overlaps), if-else is often the better tool anyhow. Case/Switch should only be used for simple mutually-exclusive value look-ups.