4 ms·
Agreed! Many of those claims completely disregard the research in visual programming that has happened in the past 30 years. Specifically the idea that it is ab
by joreg 6y ago
Agreed! Many of those claims completely disregard the research in visual programming that has happened in the past 30 years. Specifically the idea that it is about visual vs. textual seems utterly outdated now that more and more modern development environments find ways to combine the best of both worlds.
If anyone finds the time to update these claims, please consider our vvvv in your research:
- A visual programming environment for the .NET ecosystem
- Compiles to C# using Roslyn
- Can use code from any .NET library as visual code blocks
- Its language VL augments dataflow with features from OOP and functional programming, supports generics and easy multithreading
- Useful since 2002: https://vimeo.com/371511910 https://vimeo.com/371511910
Free for non-commercial use without restrictions (Windows only): http://visualprogramming.net http://visualprogramming.net
vvvv definitely doesn't solve all known issues but we hope it raises the bar for visual programming and such discussions.
- kqr 6y agoI'll preface by saying that vvvv looks impressive and certainly seems like one of the more polished options in this space. We have a type of visual programming as part of an internal configuration tool, and I will definitely look into vvvv for how things can be done differently. That said, this screenshot from one of your tutorial videos highlights the type of thing I think people are worried about: https://i.xkqr.org/screenshot_2020-04-27T09:47:46.png https://i.xkqr.org/screenshot_2020-04-27T09:47:46.png I'm not saying it's bad – it might just be a question of habit whether or not graph edges are better than named identifiers in text, but it is hard to build away, even with best in class tooling.
- joreg 6y agoIt has it's advantages and disadvantages, same goes for text-programming though: Sometimes in text you store results in badly named variables because it is hard to make up a meaningful term for each step of a computation. In those cases visual code shines because instead of forcing you to come up with a name it allows you to directly connect things with the added benefit of visualizing dataflow, thus structuring your code. If you have an algorithm though where each interim result can be clearly named, then text code shines. So roughly we argue that the more high-level your code is, the better it works visually, the more low-level it is, the better it is expressed in text. And it is therefore about a combination of both worlds. We don't have this yet in vvvv gamma (but have it in vvvv beta) that you can at any point write text-code if you prefer and wrap this in a node for further use in your visual graph.