This is a good and thoughtful essay, but in some respects reads like a rationalization of the author's preferences rather than an attempt to engage with the problems. He makes good points about the lack of formal specification, portability, and specialty software; this is indeed a problem, as all the best visual programming platforms are proprietary.

On the other hand, there's no fundamental reason that visual editors shouldn't be able to load and save source code; it's just a different way of thinking about program structure and user interface. There's already a lot of tools out there that generate dependency graphs within or alongside an IDE; the main shortcoming i see is a lack of nesting. There are few instances in which i want to see the entire structure of a program all at once, any more than I want to read all the source code in a single giant text buffer

One might equally ask if textual languages are so great, why are there so many of them? Couldn't everything be written in a nice capable high-level language like C? And of course it could, but lots of people don't like C's minimalism and lack of guardrails. It seems to me that most new general-purpose languages originate in a desire to have the computer do some of the tedious housekeeping (like casting variables) and frustration with awkward syntax.

I'm old, so when I was learning to write code it was just flat text files and every build necessitated a round of swearing over forgotten semicolons, mismatched brackets, or incorrectly spelled variables. Syntax highlighting, code folding, autocompletion, and bracket matchings which do so much to make development in a modern IDE pleasant and productive were once viewed as undesirable crutches that would lead to poor practices, lack of portability, and inaccurate second-guessing of developers' intention by the IDE, subjecting hapless coders to the tyrannical will of the interface illuminati.

I suspect that behind the aversion to visual programming lies a fear of standardization and automation that will result in widespread developer redundancy as it becomes easier for domain experts to build out their tools without code specialists, somewhat parallel to the development of electronics from hobby clubs where people helped each other with soldering irons, multimeters, and resistor identification charts to today's electronic factories populated only by pick-and-place machines assembling components too small for adult hands to manipulate at dizzying speeds.

The more automation and and ML that finds its way into IDEs, the more standardized the underlying libraries are likely to become. To the extent that programmers are freed from syntax production and housekeeping duties and processes can more easily be read (from visual graphs/charts) with domain knowledge alone, the more likely it is that the most common functions become wholly standardized, in the same way that chips are. 555 timer ICs have been around since 1971 and the most popular derivatives are dual and quad versions. Nobody is writing new and improved 555 timers and there's no real demand for them.