digitalmars.D - Visual Programming: NoFlo and Flow-based Programming
davidvm <davidvargasmoya gmail.com> writes:
Hello everyone, I just want to share this thought with you: I think a great way that could maybe help popularize the use of D, could be by developing a Flow-based programming (FBP) implementation for NoFlo and Flowhub. https://noflojs.org https://flowhub.io http://flowbased.org https://www.kickstarter.com/projects/noflo/noflo-development-environment In their Kickstarter they mentioned as stretch goals developing implementations for Java, Objective-C, and Python. It would be great to have a D one too. I understand they provide documentation and possibly assistance on implementing other languages. Eris here already worked on a D-based FBP system: http://forum.dlang.org/post/hp378v$1mhs$1 digitalmars.com Someone was already working on one for Go: https://github.com/trustmaster/goflow Visual tools like these, or like Bubble.is, are going to impact in a big way how many people build software, and what better than building in a great modern language like D. https://blog.bubble.is/who-makes-your-software-4152cfacddb7#.jwmzy3uy8 What do you think? Please comment if you think this is a good idea.
Moritz Maxeiner <moritz ucworks.org> writes:
On Friday, 14 April 2017 at 08:31:02 UTC, davidvm wrote:Hello everyone, I just want to share this thought with you: I think a great way that could maybe help popularize the use of D, could be by developing a Flow-based programming (FBP) implementation for NoFlo and Flowhub. [...] What do you think? Please comment if you think this is a good idea.The primary advantage of FBP systems imho is the ability to switch out logic of individual data processors without having to make changes to the data flow semantics, or other processors. The cost, of course, is that the overhead of modeling the data flow is generally not negligible (-> information buffers). The tradeoff seems to work well for environments with live changes (the best example imho being I/O redirection/piping in UNIX shells), but in a statically compiled language such as D you can't switch out internal parts of the application live anyway (you need to recompile), so I'm not convinced that it's worth it to have it baked in. The way I've been using FBP is this: - Data flow is modeled via either sockets, pipes, or whatever I/O scheme your OS supports - Data processors are modeled as OS processes that communicate with the chosen I/O scheme This way you have maximum decoupling of data flow and data processors and all you generally need to agree on between data processors is the serialization of data; it also happens to be what OS's are usually tuned to be extremely good at in terms of performance. In summary: Well tested, performant and usually simple (complain to your OS vendor if not) ways to construct FBP systems have existed for several decades and I think the ROI for creating custom language solutions is far too low to justify the costs.
Faux Amis <faux amis.com> writes:
On 2017-04-14 10:31, davidvm wrote:Hello everyone, I just want to share this thought with you: I think a great way that could maybe help popularize the use of D, could be by developing a Flow-based programming (FBP) implementation for NoFlo and Flowhub. What do you think? Please comment if you think this is a good idea.I know this isn't exactly the same thing, but I just wanted to mention a successful(large code/user base) visual programming system for C++, Blueprints: https://docs.unrealengine.com/latest/INT/Engine/Blueprints/GettingStarted/ It is a scripting layer between hot reloadable C++ classes. It is done via a horrible macros with all the expected problems: it can't parse everything, no templates for instance, making it yet another (sub)language you need to learn. https://docs.unrealengine.com/latest/INT/Programming/UnrealBuildSystem/index.html But still, I think there is something of value here. Being able to hook up code and tweak everything visually is great.