4 ms·

IMHO visual programming should really aim more to be a scaffolding tool - so instead of replacing the syntax to focus more on speeding up the structuring of the

IMHO visual programming should really aim more to be a scaffolding tool - so instead of replacing the syntax to focus more on speeding up the structuring of the code, helping you to easier manage and understand the blocks and the flow. Ideally it can then auto-generate the most of it and leave you to fine-tune the details of logic directly in the code (where it's faster and more expressive to be able to type the code directly).

carlmr 9y ago
Also if it's not in text, you can't use all the tools effectively, like diffing, versioning, to actually create reliable tools with few bugs. I'm very skeptical of graphical programming.
- 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.
deleted 9y ago
[deleted]

carlmr 9y ago

Also if it's not in text, you can't use all the tools effectively, like diffing, versioning, to actually create reliable tools with few bugs. I'm very skeptical of graphical programming.

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.

deleted 9y ago

[deleted]