You know, this is the first time anybody has ever been able to explain to me what Salesforce actually does.
As far as I know, VBA, VBScript, and VB.Net are "regular" Turing complete programming languages that can access anything on a Windows machine and not some sort of visual programming as such. The VBA editor is not up to modern standards, but it's pretty nice from the perspective of someone who started out in the 1980s with various MS Basics. The various forms of the language are not simpler than old fashioned Basic, but have a fair amount added.
What fits your description more, in my experience, is Microsoft Power Automate, which is a sort of low/no code environment that is only slightly better that Malbolge IMO. It makes it incredibly difficult bordering on impossible to reuse logic.
People have tried from time to time to make a programming environment to appeal to, that is graspable by, people who are allergic to entering code in a text editor. Sometimes it looks sort of like "programming" by drawing a flow chart.
And it generally, as far as I know, either fails to be easy enough for most people, or makes anything complex horribly cumbersome.
As I said, Power Automate is a (horrible) example.
"a visual programming language (VPL) is any programming language that lets users create programs by manipulating program elements graphically rather than by specifying them textually."
"The Visual Basic, Visual C#, Visual J# etc. languages of the Microsoft Visual Studio IDE are not visual programming languages: the representation of algorithms etc. is textual even though the IDE embellishes the editing and debugging activities with a rich user interface."
https://en.wikipedia.org/wiki/Visual_programming_language
So the original comment sounded perfectly reasonable to me, except it sounded like a critique of something other than VB.
I remember this from the 90s, although I never used it:
The GGP didn't call VB "no-code". That was referring to Salesforce.
Drag buttons and text fields onto a panel, click them and edit their Metadata in the sidebar, doubleclick them and Visual Studio would open a file with an auto generated OnClick() handler with an empty body and a bunch of comments surrounding it saying something along the lines of "do not edit anything before/after this line."
You'd run it by clicking the big green arrow button and I got an A in that class without ever knowing how to actually build and share an executable. I made a blackjack game and tried sharing it with some friends but it only ever ran on my machine (because only I had Visual Studio installed).
A better teacher would have helped too, haha. Nothing against him, from what I understand he was the business class teacher and taught 1 period of intro to programming because the school couldn't find a replacement for the previous years' teacher.
I never got a chance to use Delphi in any serious way,so that might have been an alternative contender,but certainly VB was orders of magnitude easier than building Windows apps in C++ and Microsoft Foundation Classes, which was the other main alternative offering at the time VB3 appeared.
Non-programmers could use it to put together something that looked reasonably good and would work reasonably well without having to fill up their heads with a hideous morass of technological complications,and if you did have past development experience then it took away immense amounts of the pain and frustration which had previously been an inherent part of programming for Windows.
Having worked for two separate companies which managed to create serious long-lived applications and make quite satisfactory amounts of money using VB5 and 6, I'd also reject the idea that the language was inherently incapable of giving you the kind of control needed to do serious real-world work.
The default solutions which the UI toolkit pointed you towards often ended up as dead ends (the data control bound to an ADO or RDO database was a particularly terrible way of managing business processes and yet it was the one which Microsoft seemed obsessed with pushing people towards) but the language offered plenty of ways to do things which weren't terrible if you took the time to work out how to do so.
Yes, if you pushed things far enough the limitations of the environment's abstractions, the fundamental sloppiness of its language design,and the choices which it decided to make for you would start to really hurt in terms of performance or ongoing maintenance. And version control was a joke, and testing and release integration were worse,and DLL hell was something which bit you on an all-too-regular basis.But you could get a pretty long way before that hurt became acute,and in the meantime you could do much that was useful and productive with much less up-front effort than you'd need to do the same thing in any current .net language,or even in something as supposedly friendly and accessible as Python.
"REPL":
What it actually looked like:
(Not my videos, just pulled of the internet)
VB made trivial projects trivially trivial. But whenever you tried to apply it to any real-world scenario, you'd get stuck trying to infer all of the "hidden state" that the too-simple interface was trying to shield you from.
I had the misfortune of working with the original no-code too, Salesforce, for a couple of years - in spite of the name, it's not all that "sales" focused; it's actually more a "VB for web-based enterprise applications" with a sales instantiation implemented in it. It had the same problems as VB, too - it was too simple for any actual problems. Simplicity was obtained by hiding details... that turned out to be crucial for basic business functionality (and don't even think about performance).