3 ms·
The ultimate dream of visual programming cannot work, at least not at present because we lack the models to represent software adequately using visual schematic
by InclinedPlane 11y ago
The ultimate dream of visual programming cannot work, at least not at present because we lack the models to represent software adequately using visual schematics.
Consider electronics. One engineer can create an electronics schematic and hand it to someone else who will build it and the second engineer will build what the first engineer specified. Right now, no such thing like that exists for software that isn't effectively a 1:1 mapping to source code. Flow diagrams and UML ain't it. And there's so much ambiguity in higher level diagrams (here's some layers, here's some lines, here's a thing that looks like a cloud) to make them only barely useful in describing software.
There is no standardized nor de facto schematic visual language of software that enables one human software engineer to specify the design (not even the full implementation) of a software system sufficiently enough to be able to hand that off to other engineers to build and be successful and predictable at doing so consistently. And if we can't get a system like that to work with humans in the loop we really aren't going to do much better purely digitally. You can program visually, but so often you end up spending more effort on minutiae than you would if you were coding textually, and so often you run into a very low ceiling where complexity becomes unmanageable.
P.S. Using interactive visual tools for things like UI design, that can be and always has been very beneficial, but that's a far cry from "visual programming".
- pjmlp 11y agoWhen I look at functional programming, I see the building blocks of digital electronics. Maybe that is the path we should take. Create IC modules for apply, map, filter, fold, ... instead of adder, half-adder and so on. I bet lots of lambda calculus programs could easily map to such constructs.