Although having a mixed textual representation is interesting. I sort of get this with the Moose platform in Pharo which I use for analysis based work. The most painful part of that though is interfacing with foreign systems. And maybe Smalltalk... not a bad language but I've been bitten by the Haskell/Lean/Idris bug. A seamless FFI experience as promised with this language coupled with a toolbox rivalling Moose would be interesting!
I believe that there is no coincidence. English is horrible at representing programming concepts. A limited set of characters, restricted left to right reading and line based structures... is this really the best way to program? Intuitively, things like recursion, data structures, processes, modularity and objects etc, etc, are better represented with diagrams... Wouldn't Circles and lines that can move diagonally across the 2D plane be better candidates as programming primitives?
It's hard to say really. Functional programming is in itself a restrictive form of imperative programming that gains power through restriction. It may very well be that English as a programming primitive gains the same type of power through restriction as well. Our brains have dedicated modules for processing language as well as dedicated modules for processing geometry, shapes and diagrams. Which module is better for programming?
Let's face it though, English as a programming primitive only became prevalent for historical reasons similar to how javascript (a shitty, shitty language) became prevalent. We like it partly because we're used to it.
There has got to be a better way.
When learning graph theory it can be quite useful at first. But once you start using set theory the graphical representation actually hides more information than it gives and intuition starts to get in the way of us discovering useful properties.
I find language to be better suited for imperative procedures. Think about it, I have a list of tasks, do I write that list in ordered English bullet points or do I draw a diagram?
Programming languages tend to be a little less expressive and elegant. They're more complicated too. For reasons of course... but I don't think I'm going to be writing algorithms and data-structures in such a tedious notation as a diagram.
Graphics are good for some things but programming I don't think is one of them.
This is pretty much why we've gone with interchangeable representations instead of going "visual only". The choice of the proper tools / representations highly depends on the context, and we want to leave that for the programmer's decision.