8 ms·

I've often wondered about this. The only graphical language I used ("G", in it's LabView incarnation) was terrible. But the basic idea: data-flowing through v

I've often wondered about this. The only graphical language I used ("G", in it's LabView incarnation) was terrible. But the basic idea: data-flowing through visible pipes is valuable. For one thing, functional programming shows that movement-of-data is a viable programming model. Secondly it's a great way to trace causality, helping with those debugging sessions you ask "how did this thing come to hold the value that it holds".

DonaldFisk 9y ago
It should not be assumed that all visual dataflow languages are similar. They're as varied as textual imperative languages. I'm developing my own dataflow language. Before I began, I had already programmed in many different languages and even designed some of my own languages and dialects. I came to several conclusions about how visual dataflow should be done, which are different from the approach taken in LabVIEW and other visual dataflow languages such as Prograph, Max, and vvvv. (1) You should only be able to connect vertices (i.e. functions) when their argument/value types are compatible. This allows you to drag an edge in the right general direction and it will find what to connect to, and also means you can develop a powerful type system with type inference built into the editor. This makes the language safe, but why stop at Hindley-Milner? You can add units (metres, flight levels, dollars, etc.) to real number types. You can give the language dependent types to make it even safer. This would eliminate many errors inherent in developing in other languages. And with a good enough type system, you don't need object orientation. (2) You can keep the language design simple. You don't need special constructs for things like iteration and conditionals. All you need are vertices (where processing is done), edges (along which values flow), constant values, and enclosures/lambdas. (3) Iteration can often be abstracted away, by having filters operating on streams of data instead of single data items. It might be worth adding an even higher level, with bidirectional flow between processes or agents. (4) You can define new types by connecting existing types, just like new functions can be defined by connecting existing functions. (5) Version control and project management can also be done graphically. I encountered, and solved, some little-known problems associated with dataflow. My language isn't yet ready for release. (There's only one of me, not a large team.) I've begun work on dependent types. I need to develop a non-trivial application, for which I have a few ideas. The language also needs a compiler. I'll add version control and project management when there's any commercial interest. Documentation (which I need to update) is at http://web.onetel.com/~hibou/fmj/FMJ.html The papers on the site describe obsolete versions of the language but are still worth reading. The tutorials are more up to date.
- biocomputation 9y ago
  Type safety isn't nearly as simple as you think when it comes to visual programming. There are lots of expressions/functions that need more than "Is the input the right 'type'?" What if the input is the right type, but doesn't have the right count for the expression? How do you deal with that? There are ways of course, but it's not so simple to figure out an elegant, scalable solution. << And with a good enough type system, you don't need object orientation. This might be true, but object orientation is a great way to have a good enough type system. << Version control and project management can also be done graphically. Yes, but it doesn't make it better. For example, in many applications you use a stream of commands and operations in the GUI to get a job done. Operations in the GUI might include things like selections, etc. In visual programming, you might convert that stream of application commands to a set of nodes. It's simple enough at first, but it turns out that things like selections -even selecting a row or two of data- are very, very tedious to do with a visual programming tool (when compared to just doing it in a GUI). What often happens is that you end up duplicating work you'd do in a more standard application by adding dialogs that allow the user to select the data using a standard GUI process and then capture their selection in the node that stores the operation. It's a bit redundant, and it doesn't get around the fact that you're still using a standard GUI to deliver a nice user experience. There's also another issue with visual programming using vertices and edges. When you write code, you might declare a variable. Then later on in the code, you refer to that variable. In a vertex-edge model, there needs to be a connection between the variable declaration and anywhere the variable is used. A vertex-edge model can get ugly and become 'hard to follow' quite rapidly. You have all these inconvenient locations for things, and it can be difficult to try and comprehend a vertex-edge model for some types of code / processes / problems. Some things are definitely better in a vertex-edge model of computation, but a vertex-edge model is not always more user friendly or more productive for many types of work. Source: have worked on very popular visual programming tools. I love visual programming for some problems, but I am aware of the many, many, many pitfalls in this approach.
  - DonaldFisk 9y ago
    > What if the input is the right type, but doesn't have the right count for the expression? I'm not sure what you mean by that. > object orientation is a great way to have a good enough type system. It means different things to different people. The type systems the various kinds of OO provide are subsets of the existing type system, which will soon be extended to support dependent typing. > In a vertex-edge model, there needs to be a connection between the variable declaration and anywhere the variable is used. There are no variables in my language. Some of your other points are valid, but I was already aware of them. Development isn't easy, or I'd have finished it by now.

DonaldFisk 9y ago

It should not be assumed that all visual dataflow languages are similar. They're as varied as textual imperative languages. I'm developing my own dataflow language. Before I began, I had already programmed in many different languages and even designed some of my own languages and dialects. I came to several conclusions about how visual dataflow should be done, which are different from the approach taken in LabVIEW and other visual dataflow languages such as Prograph, Max, and vvvv. (1) You should only be able to connect vertices (i.e. functions) when their argument/value types are compatible. This allows you to drag an edge in the right general direction and it will find what to connect to, and also means you can develop a powerful type system with type inference built into the editor. This makes the language safe, but why stop at Hindley-Milner? You can add units (metres, flight levels, dollars, etc.) to real number types. You can give the language dependent types to make it even safer. This would eliminate many errors inherent in developing in other languages. And with a good enough type system, you don't need object orientation. (2) You can keep the language design simple. You don't need special constructs for things like iteration and conditionals. All you need are vertices (where processing is done), edges (along which values flow), constant values, and enclosures/lambdas. (3) Iteration can often be abstracted away, by having filters operating on streams of data instead of single data items. It might be worth adding an even higher level, with bidirectional flow between processes or agents. (4) You can define new types by connecting existing types, just like new functions can be defined by connecting existing functions. (5) Version control and project management can also be done graphically. I encountered, and solved, some little-known problems associated with dataflow. My language isn't yet ready for release. (There's only one of me, not a large team.) I've begun work on dependent types. I need to develop a non-trivial application, for which I have a few ideas. The language also needs a compiler. I'll add version control and project management when there's any commercial interest. Documentation (which I need to update) is at http://web.onetel.com/~hibou/fmj/FMJ.html The papers on the site describe obsolete versions of the language but are still worth reading. The tutorials are more up to date.

biocomputation 9y ago
Type safety isn't nearly as simple as you think when it comes to visual programming. There are lots of expressions/functions that need more than "Is the input the right 'type'?" What if the input is the right type, but doesn't have the right count for the expression? How do you deal with that? There are ways of course, but it's not so simple to figure out an elegant, scalable solution. << And with a good enough type system, you don't need object orientation. This might be true, but object orientation is a great way to have a good enough type system. << Version control and project management can also be done graphically. Yes, but it doesn't make it better. For example, in many applications you use a stream of commands and operations in the GUI to get a job done. Operations in the GUI might include things like selections, etc. In visual programming, you might convert that stream of application commands to a set of nodes. It's simple enough at first, but it turns out that things like selections -even selecting a row or two of data- are very, very tedious to do with a visual programming tool (when compared to just doing it in a GUI). What often happens is that you end up duplicating work you'd do in a more standard application by adding dialogs that allow the user to select the data using a standard GUI process and then capture their selection in the node that stores the operation. It's a bit redundant, and it doesn't get around the fact that you're still using a standard GUI to deliver a nice user experience. There's also another issue with visual programming using vertices and edges. When you write code, you might declare a variable. Then later on in the code, you refer to that variable. In a vertex-edge model, there needs to be a connection between the variable declaration and anywhere the variable is used. A vertex-edge model can get ugly and become 'hard to follow' quite rapidly. You have all these inconvenient locations for things, and it can be difficult to try and comprehend a vertex-edge model for some types of code / processes / problems. Some things are definitely better in a vertex-edge model of computation, but a vertex-edge model is not always more user friendly or more productive for many types of work. Source: have worked on very popular visual programming tools. I love visual programming for some problems, but I am aware of the many, many, many pitfalls in this approach.
- DonaldFisk 9y ago
  > What if the input is the right type, but doesn't have the right count for the expression? I'm not sure what you mean by that. > object orientation is a great way to have a good enough type system. It means different things to different people. The type systems the various kinds of OO provide are subsets of the existing type system, which will soon be extended to support dependent typing. > In a vertex-edge model, there needs to be a connection between the variable declaration and anywhere the variable is used. There are no variables in my language. Some of your other points are valid, but I was already aware of them. Development isn't easy, or I'd have finished it by now.