To play the opposite team a bit here, I like the idea Android uses of Intents for something like this. I think it falls apart a bit in reality because app companies kinda want you in their garden and so don’t often do the work to keep things interoperable. That and the use cases from users on phones don’t frequently involve cross app functionality. But the ability is powerful for apps to say “my app needs a user photo” or one of my faves “my app needs a pgp provider (for the password store app)” and then let the other app do that piece of functionality as determined by the OS, which tracks a lot of those providers and lets the user decide which to use.
'Course, there’s a reason those things basically never catch on, which is that they don’t actually reduce the inherent difficulty of figuring out the algorithm, and for anything non-trivial messing with a whole bunch of drop-down lists and shit is more cumbersome than just typing the damn thing.
Are you talking about sending the output of one process to the input of another?
I think the shaders I’ve mentioned are a great example of that: you do something in a block, then send the result to the input of another block.
Sorry if it’s not what you mean, but my point is that, with some effort, you can create a visual representation of even the most abstract concepts. Physicists do this constantly. If we can make a visual representations of 4D, for example, what prevents us from doing the same for programming logic? Or for commands?
Things like that have been around for a long time. It was like two decades ago that I saw this shader scheme in softimage|xsi.
For implementing something like that, each node in that graph would have an array of inputs and outputs. Each of those would have a type like vector, scalar, colour, string. Then you only allow connections if the inputs and outputs match types (though you can also have conversion nodes or selectors that say pick the red channel of a colour to turn it into a scalar). Each input can be set to a constant value instead of connecting something else to it. Outputs don’t need to be connected, which is mostly useful if a node has multiple outputs. Then each node has an evaluation function that takes all input parameters and maybe internal configuration parameters (though you might as well make everything an input param since there’s no real functional difference) and uses them to calculate the outputs, which it then sends on to anything connected to those.
I’m not much of a UI guy but displaying it for the GUI would just involve drawing boxes or some shape for the node, then spaces for each of the inputs on the left side and outputs on the right side maybe colour code them by type, and lines running along the connections. Then just add the name and/or other visual information you want to display and positional information to let users move it around their work area.
This right here, you can gui a single program, but with pipes we can chain nearly infinite programs. No way can you make a gui that is that flexible, I refuse to believe until I see it
How would you implement piping in GUI?
Could you show us an example program with a GUI you created for this?
To play the opposite team a bit here, I like the idea Android uses of Intents for something like this. I think it falls apart a bit in reality because app companies kinda want you in their garden and so don’t often do the work to keep things interoperable. That and the use cases from users on phones don’t frequently involve cross app functionality. But the ability is powerful for apps to say “my app needs a user photo” or one of my faves “my app needs a pgp provider (for the password store app)” and then let the other app do that piece of functionality as determined by the OS, which tracks a lot of those providers and lets the user decide which to use.
https://en.wikipedia.org/wiki/Automator_(macOS), or in general, https://en.wikipedia.org/wiki/Visual_programming_language
'Course, there’s a reason those things basically never catch on, which is that they don’t actually reduce the inherent difficulty of figuring out the algorithm, and for anything non-trivial messing with a whole bunch of drop-down lists and shit is more cumbersome than just typing the damn thing.
Are you talking about sending the output of one process to the input of another?
I think the shaders I’ve mentioned are a great example of that: you do something in a block, then send the result to the input of another block.
Sorry if it’s not what you mean, but my point is that, with some effort, you can create a visual representation of even the most abstract concepts. Physicists do this constantly. If we can make a visual representations of 4D, for example, what prevents us from doing the same for programming logic? Or for commands?
Yeah, and doing this would take significantly longer to use every time than typing up a chain of commands in a terminal.
Wow, you created this program for creating shaders visually? That’s impressive! You mind sharing the source code?
Things like that have been around for a long time. It was like two decades ago that I saw this shader scheme in softimage|xsi.
For implementing something like that, each node in that graph would have an array of inputs and outputs. Each of those would have a type like vector, scalar, colour, string. Then you only allow connections if the inputs and outputs match types (though you can also have conversion nodes or selectors that say pick the red channel of a colour to turn it into a scalar). Each input can be set to a constant value instead of connecting something else to it. Outputs don’t need to be connected, which is mostly useful if a node has multiple outputs. Then each node has an evaluation function that takes all input parameters and maybe internal configuration parameters (though you might as well make everything an input param since there’s no real functional difference) and uses them to calculate the outputs, which it then sends on to anything connected to those.
I’m not much of a UI guy but displaying it for the GUI would just involve drawing boxes or some shape for the node, then spaces for each of the inputs on the left side and outputs on the right side maybe colour code them by type, and lines running along the connections. Then just add the name and/or other visual information you want to display and positional information to let users move it around their work area.
This right here, you can gui a single program, but with pipes we can chain nearly infinite programs. No way can you make a gui that is that flexible, I refuse to believe until I see it