I'm not saying that Blocks is a good programming language, nor defending it as a go-to tool; I know it is quite cumbersome to build programs in it - but I think it's largely because it's imitating classic imperative languages instead of being designed from the bottom up to take advantage of visual representation and interactive development. Still, it may be a very good introductory tool for learning classic-style programming (certainly better than Python for a primary school classroom; direct manipulation is just so superior for the first impression, when getting the students motivation is make-or-break).

I was referring to your defense of textual programming as inherently superior, which I don't see as justified. Classical languages have a refinement over decades that visual languages lack, but I think it is possible, and I think we are getting to a point where building such languages is starting to become viable.

> I'm not saying text entry is free. I'm saying that the palette concept is more expensive - even for visual learners

This is simply not true. Recognition is easier than recall, even for textual learners; so even if toolbars require more steps, those are way easier steps. Even if you're talking about expensive in time and not actual effort, physically entering code is the task that less actual time takes of programming: thinking what code you need to include takes much more time, so anything that reduces that time will accelerate development. Programmers usually are not aware of this fact because they are distracted by all the thinking, but the actual input method is usually not that relevant except for people with disabilities. (Btw visual vs word learners is largely a myth; the best style is usually to the task you're doing, and we are all able to do both styles. When I say I have a preferred style, I do find visual tasks easier than those requiring word recall skills).

Also, nothing prevents visual languages from incorporating fast introduction tools other than palettes, like keyboard accelerators and contextual search - i.e. you type the name of a component and it appears at the cursor point; this would make them work with identical interactions as pure text programs. (BTW, I consider intellisense-autocomplete to be a visual tool; it favors recognition over recall by showing you the list of available options).

What I consider a programming language is somewhat different from what think of as visual languages (which are primarly the flow-based block graphs; they have their place, but are too highly oriented to bulk data processing). For me, the ultimate visual language is the spreadsheet - a functional reactive environment where the user can freely position information and transformations in more than one dimension, and manually decorate them with as many cues, reminder text and color codes as needed.

Some new development environments are growing a modern style, highly evolved with respect to the classic IDE, which is still based on the batch model of the mainframes in the 60s:

* Jupyter-like notebooks bring some of the spreadsheet benefits to classic languages;

* relational models that show data together with structure, like Airtable, is an example of these breed of visual tools for building data-transforming automations;

* wikis work as visual storage that makes it easier to structure and organize hierarchical content;

and so on. Modern development environments will start incorporating all these models, relying less in pure abstraction and running the program in your head as requirements to build programs.