My point is - I could either waste time piecing together a visual diagram like that (which is going to be fairly different visually from use case to use case - e.g., image processing vs. text processing, resulting in more mental overhead) - or I could look at code, which is (for me, at least) simply much quicker and easier to understand (in many cases).
Furthermore, these are idealized examples. Start throwing in error handling. Concurrent processes. I predict that diagrams that can fully capture complex systems will lean far more towards "visual overload" than not, and really, how useful is a tool like this at that point?
Maybe something like this could be fine if it's just high-level processes, but it just falls apart the more detailed things get.
My suspicion is that as your model approaches the complexity of real-world systems, the visual language you're creating will be unable to efficiently capture that complexity.
Would love to be proven wrong.
Moreover, nothing prevents you from writing code, as they say Luna maps 1:1 to the code they show next to the diagrams.
But when you want a higher level view of the whole program architecture, code can't show you that -- with code you only get some source file or another, and even that rarely all of it in a single screen. A visual representation can, and it can group larger units in single modules (e.g. your packages).
>My suspicion is that as your model approaches the complexity of real-world systems, the visual language you're creating will be unable to efficiently capture that complexity.
One can even make a trivial visual language of 2-3 node types that is turing-complete and can capture ANY complexity. Luna is, of course, far better than that. As for sufficiency, this depends on the level that one wants to play. You might still write code at the lower function level, but if the language makes it easy to group functionality in larger visual units, it would be great for the larger structure, and also great for configurable parts meant for non-coders.
I don't disagree with you on the first part - that you can make a trivial visual language that can capture any complexity. The challenge is - can a user "visually" parse through the visual representation of that complexity?
I haven't seen any evidence that Luna can effectively do that at scale. Until I do, I remain extremely skeptical.
What exactly looks difficult to parse about the visual example going:
read -> grade -> transform -> grade -> final touches -> write
To me it's a very obvious image processing pipeline, reading the image, grading (in image processing terms this means color work, e.g. adding a hue to the highlights), doing a transformation (e.g. some rotation, or similar), grading again, and finally writing the result to disk.
If you wonder what "exactly" they are doing, then unless you open each box (like the 2nd "grade" box is open), they're not meant to tell you. Closed, they're meant to give a high level overview of how your functions etc are connected.
Think of it as seeing your code in your programming editor with the functions folded.
The second example is also obvious. There's a selectable (by dropdown) input source, currently set to read posts from Twitter. Posts read are then fed into a (switchable on/off) filter, that either passes them all, or only keeps the one from Europe.
Of course you need to spend a few minutes (or days) to familiarize yourself with the visual language (like you would for new terms if you met a new programming language), e.g. how the toggle icon means a "switchable" option.