4 ms·

I have seen visual dataflow languages and even worked on some of them. They usually work better in specific domains like stream processing, control systems, sig

by rdtsc 8y ago

I have seen visual dataflow languages and even worked on some of them. They usually work better in specific domains like stream processing, control systems, signal processing and such. Even then, once a "program" gets complex it can get tangled fast. A node with 3000 edges starts to look messy. There are some things you can do to fix it but then you just kind of wish to use a simple script. As for general computing, the most thought out language I've seen so far is probably https://en.wikipedia.org/wiki/DRAKON https://en.wikipedia.org/wiki/DRAKON. Apparently you can now even try it online: https://drakonhub.com/try-me?example=mind157 https://drakonhub.com/try-me?example=mind157 I like Full Metal Jacket in that it starts with a functional approach (it seems to be based on LISP) and might actually be a good way to introduce functional programming to newcomers. For example, here you just have a "factorial" node when you define the factorial function: http://www.fmjlang.co.uk/fmj/tutorials/Recursion.html http://www.fmjlang.co.uk/fmj/tutorials/Recursion.html Some people really struggle with recursion initially and if they are visual learners this might be helpful.

userbinator 8y ago
You may find this interesting: someone using DRAKON to model and simulate the 6502 CPU at the transistor level. He is, not surprisingly, Russian: http://forum.6502.org/viewtopic.php?f=8&t=2208 http://forum.6502.org/viewtopic.php?f=8&t=2208 (Russian) video: https://www.youtube.com/watch?v=43zPp01i6So https://www.youtube.com/watch?v=43zPp01i6So
- rdtsc 8y ago
  Thank you, that was neat. I speak Russian and it was fascinating to watch someone build software in DRAKON.
RantyDave 8y ago
Visual effects lives breathes and eats visual languages. It's not necessarily a good thing - people get (very) competent with them then start writing C++ using the same style namely, copy-n-paste a go go. Refactoring fun for all the family.
- coldtea 8y ago
  That's C++'s (and its IDE's) problem though. In visual languages copy-n-paste is not copy and paste, it's reusing a component.
dkersten 8y ago
> Even then, once a "program" gets complex it can get tangled fast. In my experience with both visual and textual languages, the same happens in textual languages too, except we’re trained to use software engineering principles to attempt to manage the complexity (to varying levels of success). In my (somewhat limited) experience with visual languages, if you apply those same principles (especially some of the OO ones like encapsulation) and factor things into their own functions/nodes, it’s manageable too. Whether better or worse than textual probably depends on the use case and persons comfort level with either type of language and in practice most visual code I’ve seen was not written by a programmer and therefore the author did not know the software engineering principles that would have helped keep their code manageable.
- rdtsc 8y ago
  > except we’re trained to use software engineering principles to attempt to manage the complexity Yeah good point. I think visual languages are often used by people who haven't had experience with software engineering, and that's fine, it's one of their main selling points. But think there is a general limitation when abstracting connection between nodes. In a programming languages, one could for example do a loop and connect an array of a thousand structs to point to some pointer. In a visual language it would be drawing thousands of connections/wires by hand between nodes. So visual languages in a way hit an abstraction ceiling if you will. In some domains it doesn't matter and there are a few trick around it, so there is room for such languages, but I am pessimistic about a general approach.
  - dkersten 8y ago
    In my (again, limited) experience with visual languages, you don’t need thousands of connections. There’s nothing technically preventing a visual language from having complex data types flow through connections and I know some visual languages can unpack arrays (that is, the node outputs a value for every element in an array) so you can have a similar loop. (I’ve seen the reverse too: packing lots of individual items into an array). If I were to design a visual language, I’d have nodes to access keys in KV tables, iterate through lists/arrays/trees and everything else I take for granted in textual languages. If a language doesn’t support that, then it’s probably because it was deemed unnecessary for the target users, not because of an inherent shortcoming in visual languages. But I’ve only used a small number of visual languages (Max/msp and Synthmaker being the two I’ve used most), so maybe you do see crazy numbers of connections in the wild (but again, I feel this could be avoided if the language designers wanted to)
ken 8y ago
> A node with 3000 edges starts to look messy. There are some things you can do to fix it but then you just kind of wish to use a simple script. A text-based function with 3000 lines starts to look messy, too. That's purely a function of size, not building materials. The analogous solution to "a simple script" is "a simple graph", i.e., abstraction.
- rdtsc 8y ago
  > The analogous solution to "a simple script" is "a simple graph", i.e., abstraction. Right and abstraction is exactly what doesn't work well with visual languages. With a script you can do a for loop from 1 to 3000. With 3000 components connected to one node in a visual language there is not obvious facility to handle it. You can think of group functions in components/namespaces/folder maybe. Or say generate implicit connections where they are not really drawn on the screen.
  - ken 8y ago
    What visual language are you using? All of them that I’ve used have for-loops, too.
    - rdtsc 8y ago
      A proprietary one. A for loop to create connections between nodes? How would that work? It would have to be a self-modifying connection graph.
nikofeyn 8y ago
> I have seen visual dataflow languages and even worked on some of them. have you ever actually used one? > Even then, once a "program" gets complex it can get tangled fast. because this is a common complaint, but it applies to text-based languages as well. what happens with visual languages is that it's easy to get going, but then people don't apply the same software engineering principles once projects get large. i do, and i find visual languages no worse than text-based languages. in some ways, there are direct improvements. so basically, these complaints are levied by people who have never seriously programmed in a visual programming language. > A node with 3000 edges starts to look messy. There are some things you can do to fix it but then you just kind of wish to use a simple script. this doesn't even make sense. i use labview, arguably the best designed and most powerful visual programming language environment around (and a powerful environment period). it isn't even possible to create a node with 3000 edges (well maybe for some definition of the word node, but it would be an extreme case and an exercise in shenanigans). what you've stated here sounds like "a function with 3,000 arguments starts to get messy". it's a ridiculous statement. > As for general computing, the most thought out language I've seen so far is probably DRAKON have you used labview? you can program windows, mac os x, linux, real-time linux, and fpga, all with the same language. this inculdes modern GUIs, web-servers, actor-based systems, oop, etc. it's extremely powerful. it has its warts, and i have many complaints, but none of them are the usual complaints by people who have opinions against visual languages despite not having used one.

by rdtsc 8y ago

userbinator 8y ago

You may find this interesting: someone using DRAKON to model and simulate the 6502 CPU at the transistor level. He is, not surprisingly, Russian: http://forum.6502.org/viewtopic.php?f=8&t=2208 http://forum.6502.org/viewtopic.php?f=8&t=2208 (Russian) video: https://www.youtube.com/watch?v=43zPp01i6So https://www.youtube.com/watch?v=43zPp01i6So

rdtsc 8y ago
Thank you, that was neat. I speak Russian and it was fascinating to watch someone build software in DRAKON.

RantyDave 8y ago

Visual effects lives breathes and eats visual languages. It's not necessarily a good thing - people get (very) competent with them then start writing C++ using the same style namely, copy-n-paste a go go. Refactoring fun for all the family.

coldtea 8y ago
That's C++'s (and its IDE's) problem though. In visual languages copy-n-paste is not copy and paste, it's reusing a component.

dkersten 8y ago

> Even then, once a "program" gets complex it can get tangled fast. In my experience with both visual and textual languages, the same happens in textual languages too, except we’re trained to use software engineering principles to attempt to manage the complexity (to varying levels of success). In my (somewhat limited) experience with visual languages, if you apply those same principles (especially some of the OO ones like encapsulation) and factor things into their own functions/nodes, it’s manageable too. Whether better or worse than textual probably depends on the use case and persons comfort level with either type of language and in practice most visual code I’ve seen was not written by a programmer and therefore the author did not know the software engineering principles that would have helped keep their code manageable.

rdtsc 8y ago
> except we’re trained to use software engineering principles to attempt to manage the complexity Yeah good point. I think visual languages are often used by people who haven't had experience with software engineering, and that's fine, it's one of their main selling points. But think there is a general limitation when abstracting connection between nodes. In a programming languages, one could for example do a loop and connect an array of a thousand structs to point to some pointer. In a visual language it would be drawing thousands of connections/wires by hand between nodes. So visual languages in a way hit an abstraction ceiling if you will. In some domains it doesn't matter and there are a few trick around it, so there is room for such languages, but I am pessimistic about a general approach.
- dkersten 8y ago
  In my (again, limited) experience with visual languages, you don’t need thousands of connections. There’s nothing technically preventing a visual language from having complex data types flow through connections and I know some visual languages can unpack arrays (that is, the node outputs a value for every element in an array) so you can have a similar loop. (I’ve seen the reverse too: packing lots of individual items into an array). If I were to design a visual language, I’d have nodes to access keys in KV tables, iterate through lists/arrays/trees and everything else I take for granted in textual languages. If a language doesn’t support that, then it’s probably because it was deemed unnecessary for the target users, not because of an inherent shortcoming in visual languages. But I’ve only used a small number of visual languages (Max/msp and Synthmaker being the two I’ve used most), so maybe you do see crazy numbers of connections in the wild (but again, I feel this could be avoided if the language designers wanted to)

ken 8y ago

> A node with 3000 edges starts to look messy. There are some things you can do to fix it but then you just kind of wish to use a simple script. A text-based function with 3000 lines starts to look messy, too. That's purely a function of size, not building materials. The analogous solution to "a simple script" is "a simple graph", i.e., abstraction.

rdtsc 8y ago
> The analogous solution to "a simple script" is "a simple graph", i.e., abstraction. Right and abstraction is exactly what doesn't work well with visual languages. With a script you can do a for loop from 1 to 3000. With 3000 components connected to one node in a visual language there is not obvious facility to handle it. You can think of group functions in components/namespaces/folder maybe. Or say generate implicit connections where they are not really drawn on the screen.
- ken 8y ago
  What visual language are you using? All of them that I’ve used have for-loops, too.
  - rdtsc 8y ago
    A proprietary one. A for loop to create connections between nodes? How would that work? It would have to be a self-modifying connection graph.

nikofeyn 8y ago

> I have seen visual dataflow languages and even worked on some of them. have you ever actually used one? > Even then, once a "program" gets complex it can get tangled fast. because this is a common complaint, but it applies to text-based languages as well. what happens with visual languages is that it's easy to get going, but then people don't apply the same software engineering principles once projects get large. i do, and i find visual languages no worse than text-based languages. in some ways, there are direct improvements. so basically, these complaints are levied by people who have never seriously programmed in a visual programming language. > A node with 3000 edges starts to look messy. There are some things you can do to fix it but then you just kind of wish to use a simple script. this doesn't even make sense. i use labview, arguably the best designed and most powerful visual programming language environment around (and a powerful environment period). it isn't even possible to create a node with 3000 edges (well maybe for some definition of the word node, but it would be an extreme case and an exercise in shenanigans). what you've stated here sounds like "a function with 3,000 arguments starts to get messy". it's a ridiculous statement. > As for general computing, the most thought out language I've seen so far is probably DRAKON have you used labview? you can program windows, mac os x, linux, real-time linux, and fpga, all with the same language. this inculdes modern GUIs, web-servers, actor-based systems, oop, etc. it's extremely powerful. it has its warts, and i have many complaints, but none of them are the usual complaints by people who have opinions against visual languages despite not having used one.