I'm seeing the proliferation of this false dichotomy again between text and visuals. Text IS a visual. This is a more relevant point than it appears at first glance. It indicates that you can mix text with other kinds of visuals. Despite what has historically been produced, the other kinds of visuals do not have to be in the form of boxes and arrows, or lego blocks, or anything which has proven itself objectively bad through 5 decades of repeated failed attempts. I believe people designing these visuals just need to try something different. It's true that there aren't many concepts in an abstract language that can even be visualised. But there are some. Two major dimensions are composition and choice. Almost every language construct in any functional language is just a combination of these. (Imperative languages throw in 70 other "features" which I argue makes visualisation a fool's errand). Function application, function composition, product types, and sum types are just different flavours of composition. If-expressions, case-expressions, and pattern matching are all just different flavours of choice. Visualising these naively leads you to some kind of graph, which leads to a naive boxes and arrows visualisation. But Stefan rightly points out that humans are good at recognising names, and are bad at navigating a soup of arrows, so we should probably use names as the building blocks of the visualisation. This does not necessarily lead to "text-based programming", but it does lead to a generous use of text within the visualisation.

+1. And since we name functions, but almost never name units of control flow (branches, loops, scopes, sequences, etc), I think there's still room for non-textual coding there.