first off, many thanks for the feedback.

> - 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)

copying can be made much easier. on these kind of features, we are acting on user feedback to prioritize. but since this one specifically is one that my co-founder has been bugging me since the day he joined, I don't think it'll be too much down the pipeline.

also, automatically re-ordering the boxes to get the flatest version of the graph (which seems to correlate to the "cleanest code") is something on our mind, which would alleviate that issue.

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

that is partly by design to encourage modularizing. on that front, we have gone for possible overshooting and then slowly tuning towards the optimal point.

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

is that because of the increased inefficiency of switching between sub-diagrams? if that is the case, thats also a user feedback that has been on our radar for sometime and will probably tend to it soon-ish.

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

actually it does not need to be sequential for proper error handling. each node in the graph is equipped with its own error-handling, i.e. if an error is somehow thrown during its execution the node will report it properly, which has in many cases led to faster detection of error-sources in the context of the projects we have done with CONNECT up until now. still, admittedly the error-handling system needs to become more robust, and all of this is basically only referring to errors that you wish you would catch and fix during development phase. for errors that should be handled on runtime, yes they need to be somewhat dragged along, which I do not necessarily see as a bad thing, as it forces you to explicitly choose the corner-cases that might occur and need to be handled in runtime. this separation actually helps completely avoid using one big 'try/catch' that would blind you to 'bugs' that should not make it to runtime in the first place.

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

that is true as mentioned in the article as well. we've tried to make it really human-friendly, however we have plans for further tooling specifically on that front.

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

that is true unfortunately. personally I am still thinking on how to represent such dynamic branching within the graphs without causing more confusion. since this is also a corner case, we have kept it on the drawing board until a proper solution is found.

The "crazy" label is merely a hint to the inherent resistance of most programmers towards "visual" tools, disregarding them for reasons not-withstanding in this case. yet here it seems like actually the "visual" way is the approach with more fine-control and detailed (and maybe sometimes more complex as you embrace the async nature further). It was by no mean an indicator of any of this being a "new" or "novel" idea.

p.s. while it originally used to be acyclic graphs, I had to relax that constraint due to people's request.