At the heart of the issue is the concept that “computer programming” - which is to say, writing code - is a constraint on the development of software. That there is some “higher level” on which people can operate, where development is much simpler but the end results in some way the same.Specifically, the idea of writing business logic in text form according to the syntax of a technical programming language is anathema. To make an analogy: it’s a little bit like saying all software developers are like car mechanics, who get into the guts of an engine. But most people just need to be able to drive the car, and a simpler interface can be put on top of the machine (a steering wheel and some pedals).
This is a bad, bad analogy. There is a higher level on which people can and do operate, and it's called 'drawing flowcharts'.
The correct analogy for the case of a car is not abstracting the work of car mechanics to be more like a car dashboard, but making it easier to view car schematics as opposed to textual descriptions that convey the same information but have to be processed in linear rather than holistic fashion.
To be sure, there are many 'build without code' tools available that over-simplify or promise that to never expose the user to any complexity, and that is indeed a delusion at best and a lie at worst. But the idea that complexity can only be effectively represented in textual form by elaborate syntax is equally absurd; it's simply a product of what technology was practical at the time. It's not better, as such; it's just what he have a lot of.
Consider assembly language. I love it; it is so basic that it takes me back to the delight of understanding Towers of Hanoi type problems and I get a kick of out of reverse-engineering things in a debugger. But writing any kind of large project in assembler is not a good idea if you want anyone else to get involved, because it's not very accessible - hence the popularity of high level languages.
But high level languages are in many ways a product of keyboard input and monitors as assembler was a product of punch cards and blinkenlights. They're great, but they're also hard to read - and so as time has gone by things like syntax highlighting and autocompletion have become standard in editors. You could learn to code without any syntax highlighting; it didn't exist when I started. You could learn to just read everything in assembler.
But once you have a useful tool available, demanding that people refrain from using it because it makes things too easy is just expressing a sort of anxiety about the existence of shortcuts that were not available to you, and the resulting ability of others to catch up to you in less time than it took you to learn.
So it is with the 'no code' trend. People who spent a long time learning to code have developed very valuable engineering skills, but that doesn't make the more high-level component-assembly approach of no-coders invalid. The no-code people want to focus on domain problems (which they often understand very, very well) and not get caught up on the minutiae of language syntax; they're comfortable with the fact that someone else has been able to automate that in such a way that the computer does most of the work. Fighting this trend is like getting hung up on the inadequacies of Lego - all that blockiness, the general inefficiency, and path-dependency problems of building things out of lego rather than making them from scratch - while overlooking the fact that it's so easy that kids can do it and that it's a fantastic way to quickly prototype any sort of toy you want.
In the first [flowchart] example, I need to know how the visual environment works. In the second, I need to know a language and a development environment. But both of those are skills that are easily acquired.
No! one of these things is not like the other. It's waaay easier to understand flowcharts than it is to acquire all that syntactical and semantic knowledge. This isn't to deny the utility of text for specificity, but to point out that it only seems equivalently easy because the author already learned to write code and has not yet learned visual programming in depth. I encourage people who doubt this to spend some time building actual electronic circuits. After all, programming is just high level circuit design, so it should be easy, right? And if you're already good at electronics, why not just get into making your own components? After all, making electronic components like capacitors and resistors is just high level material science, right? Real programming is about pulling stuff straight off the periodic table and just working out the math, right?
Of course it isn't, circuit design is its own discipline in which you spend a great deal of time wresting with (or exploiting) the fuzziness and quirks of electrical current flow instead of being able to take exactitude and precision for granted, and so on down. Conversely, the path forward for established coders in an increasingly modular world is exploiting their acquired skills of extreme precision and efficiency to make better modules that do things by magic and finally fulfil the promise of libraries to provide collections of functions that Just Work and do so reliably and speedily enough that they don't need to be rewritten over and over and it doesn't matter what language paradigm the downstream user has in mind.
In the article's example, all the downstream user cares about is whether the email validator is RFC5321/2 compatible and what speed throughput it has. It shouldn't matter how it was made, the same way it doesn't matter to an electronics hobbyist precisely how a 555 timer works* and it doesn't matter to a low-level circuit designer how it gets manufactured.
* although when you do start caring about how a 555 timer works, this is the most fun way to explore it: https://www.adafruit.com/product/1526?gclid=CjwKCAiAx_DwBRAf...