[smolder]

I do not believe for a second it's a mistake to have visual representation or manipulation of software, it's just exceedingly difficult to make anything as versatile as text grammars and compilers. No one's done an adequate job because the ROI is terrible for building such things when you can't depend on massive adoption, which you can't.

[khooke]

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.

[smolder]

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.

[pfdietz]

I think it's a proven mistake to use visual representations in place of textual representations for creating software. The information density is low, it's difficult to work with, browse, and search, and (a real killer) merging in version control systems is a nightmare.

[khooke]

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.