3 ms·

There is a big problem with graphical programming: it is very hard to diff graphs in a graphical way. How can you even give review comments on changes? How woul

There is a big problem with graphical programming: it is very hard to diff graphs in a graphical way. How can you even give review comments on changes? How would an automatic merge work? Also, the benefit of graphic representation of an algorithm is that it gives an overview that is easier to understand. But the whole graph with the real details, is just harder to understand. But the details are necessary, they make simplistic software smarter and better.

solarkraft 4y ago
You're right: The tooling ecosystem for text-based programming is already very mature, which is why I wouldn't want to replace it. Current programming languages are stored as text anyway (trying to replace an entire established ecosystem without any steps in between doesn't really work, see Microsoft's constant failures attempting to bundle new things). That's why my imaginary editor would work with that format, just in a more semantic/graphical way - as an enhancement rather than a totally new way of doing things. In fact the most practical way to go about it (let's work within the current ecosystem as much as possible!) would probably be to make a VSCode extension.
derefr 4y ago
You can do all that at the text level, if it makes the tooling easier; the tooling would just be operating on a canonically-chosen textual projective representation of graphical code (think: `go fmt`, but as a FUSE mount!), rather than against canonically textual code. Changes on the text layer would be propagated back down as changes to the persisted binary AST that the text represents. As such, any Unix tool used to manipulate text (and thereby textual source code), e.g. diff(1) + patch(1), could be used to manipulate the persisted binary AST through the text. `sed -i` would still work, even. But you could also have other tools, that manipulate the underlying binary AST directly; where the textual projection would be the thing to update in response.
- shakow 4y ago
  Honestly, I'm under the impression that you have basically just reinvented Lisp ;) Or any homoiconic language.

solarkraft 4y ago

You're right: The tooling ecosystem for text-based programming is already very mature, which is why I wouldn't want to replace it. Current programming languages are stored as text anyway (trying to replace an entire established ecosystem without any steps in between doesn't really work, see Microsoft's constant failures attempting to bundle new things). That's why my imaginary editor would work with that format, just in a more semantic/graphical way - as an enhancement rather than a totally new way of doing things. In fact the most practical way to go about it (let's work within the current ecosystem as much as possible!) would probably be to make a VSCode extension.

derefr 4y ago

You can do all that at the text level, if it makes the tooling easier; the tooling would just be operating on a canonically-chosen textual projective representation of graphical code (think: `go fmt`, but as a FUSE mount!), rather than against canonically textual code. Changes on the text layer would be propagated back down as changes to the persisted binary AST that the text represents. As such, any Unix tool used to manipulate text (and thereby textual source code), e.g. diff(1) + patch(1), could be used to manipulate the persisted binary AST through the text. `sed -i` would still work, even. But you could also have other tools, that manipulate the underlying binary AST directly; where the textual projection would be the thing to update in response.

shakow 4y ago
Honestly, I'm under the impression that you have basically just reinvented Lisp ;) Or any homoiconic language.