It sounds like you're judging all of visual programming based on one project, written in one language. You don't even say what language it was.
Am I allowed to condemn all textual programming based on the last textual program a company asked me to maintain? It had a single function over 1500 lines long, which took over a dozen parameters, had well over a dozen exit points, re-used variable names and values (sometimes unintentionally) between otherwise independent sections, and had zero documentation. And I had to fix a bug in it. "Impenetrable" does not begin to describe it. Text-based programming is a disaster.
That is how it is in every visual language though. It's too much hassle to add comments, so nobody does, and it's too hard to organise things nicely, so nobody does that either. You end up with literal spaghetti code.
I don't say because I don't remember. It was about 10 years ago and I've pushed it completely out of my mind. I do remember it was a Microsoft product. I never want to see it again, and due to a job change between then and now I doubt that I ever will.
Maybe you're right that it's unfair for me to dismiss the paradigm as a whole based on one bad experience. But it just seems to me that the mindset lends itself to a write-only environment.
Am I allowed to condemn all textual programming based on the last textual program a company asked me to maintain? It had a single function over 1500 lines long, which took over a dozen parameters, had well over a dozen exit points, re-used variable names and values (sometimes unintentionally) between otherwise independent sections, and had zero documentation. And I had to fix a bug in it. "Impenetrable" does not begin to describe it. Text-based programming is a disaster.