Ooolin

Replace with "Element" with "Class" and "Attribute" with "Property" in your examples.

It's your job to decide how the data should be structured, in any language.

I would do the following :

  <user name="alice">
    <groups>
      <group uid="wheel"/>
      <group uid="admin"/>
      <group uid="sudoers"/>
    </groups>
  </user>

- Syntax is slower to write. Copying and pasting is a non trivial operation. In order to benefit for the clean representation of the process, you need to spend a good amount of time ordering the boxes around. The representation can be misleading (wires crossing, overlapping boxes)

- Very low density of information per pixel compared to any textual language (if no zoom feature). Any long name that has to be rendered on screen become fugly. Since we tend to order the boxes in a process from left to right, only the equivalent of a single line of code can be represented on the screen at once when displaying the names of variable and functions.

- Functions / sub diagrams generally sit in their own separate window (or worse, file). This discourage making functions, to a degree depending on how good/bad the UI is. Getters and setters in OO visual code are a pain.

- Execution order is not guaranteed to be sequential, so no try/catch structure. Error handling has to be explicit. Witch mean dragging along an additional error variable all over the place.

- The graph representation doesn't translate well into source control and diff tools.

- If you need to fire an arbitrary number of parallel stuff at runtime, you still need a "call this asynchronously" structure.

Coming from a LabVIEW dev. The benefits described in the article are still absolutely valid.

Is the author aware of Dataflow programming ?

These do give the described benefits, however, the tradeoffs are massive.