3 ms·
Unfortunately, there's a long history of graphical programming being foisted upon text-centric domains, which is just as bad as the reverse, so you're right to
by spiralganglion 9y ago
Unfortunately, there's a long history of graphical programming being foisted upon text-centric domains, which is just as bad as the reverse, so you're right to be skeptical. But if you shift perspective to another domain, graphical (or otherwise non-textual) programming becomes much more appealing.
For example: Game devs build themselves sandbox environments in which they can test out their physics engine, dynamic music systems, animation playback, etc. These sandboxes are like REPLs, but for non-textual data. One can imagine how much nicer it would be if the full system's code were represented first-class inside that sandbox, so that you were introducing and manipulating system abstractions close to the truest representation of the data, rather than having to leave the sandbox to go back to your text editor to make system tweaks, far away from the data.
Still skeptical about why that might be nice? Your text editor and terminal know nothing about the full, live representation of the data, so they do nothing to help you work in that domain. The nice things you get when working with text — diffs, versioning, etc — you don't get the physics engine / music engine / animation engine equivalents unless your code is somehow present in the same space as the live data.