I worked at 3 different companies in the mid 1990s that had teams actively working on COBOL systems and they were all using mainframe based version control systems. I think the issue at this point is whether those version control systems are still being maintained and those orgs are continuing to pay for the licenses for those systems, probably during years where you weren't even planning on using them.

Given the current day struggle to merge code with whitespace differences, merging differently arranged visual programming elements where the end result is the same but the positioning of the elements is just different sounds like a tough problem. Although linking of elements is probably key, rather than visual positioning. I imagine this is something IBM VisualAge had to deal with back in the late 90s. If I remember right local history was a key feature of VisualAge, a feature that carried across to Eclipse and is still there today.

I think the limitation that no-one has managed to solve is that visual programming paradigm approaches tend to focus on solving a specific type of problem (drag and drop GUI builders are a perfect example), and this means their usage is narrow and they're never been widely adopted. Building a generic visual programming tool that can be used to solve any type of business problem across any business domain is very difficult if not dare I say it impossible.

I see it as just a very difficult problem. Flip the problem around and you can maybe see my point of view. IDEs for text programming are getting more intelligent, to the point where in certain languages, arranging function calls and assigning parameters could almost be done completely with autocomplete menus. Go a few steps further and you can connect these things without the frequent naming-of-things exercise that programmers undergo.

Part of the reason I am so bullish on visual programming is that it lets us skip the excessive naming-of-things that is part of text programming. I would rather copy-paste a pile of colors and shapes that describes an algorithm and connect it to the right inputs and outputs. I think nameless shapes would be more immediately recognizable than identifiers from all the various naming schemes people use in their code.

Re. thinking better: I think we forget programming languages are just tools. (Almost) anyone can learn to program but it doesn't mean they're good at solving problems or are able to bring innovative/new/better solutions to solving current problems.

Reading and writing are just tools too.

Other commercial development tools popular in the same time period just before Java's release also used p-code, e.g. Powerbuilder.

Side comment: most new developers tend to ignore/not read compile or runtime error messages and ask for help before even realizing the cause of the problem they're trying to fix is right there in front of them. Better error messages for 'beginners' has questionable benefits for developers just getting started, until they get to the point where they realize error messages are actually useful

There are two kinds of new developers:

a) new developers in general (totally new to programming)

b) developers new to this specific programming language

I'd be curious what the percentages are, but my personal hunch is that for any specific language there are more in category b) than a).

And for category b), those are definitely helped by error messages.