5 ms·

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

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.
- biocomputation 9y ago
  > What if the input is the right type, but doesn't have the right count for the expression? Let's say you have type T. T stores one or more pictures. Let's say you have a vertex in the vertex-edge graph that wants an input of type T, but it also wants a T that stores a specific number of pictures. You can ensure basic type safety by requiring an input T for the vertex, but you cannot ensure expression safety since T satisfies the type safety requirement, but not the requirements of the expression represented by the vertex. In your initial remarks, you mentioned type safety as a relatively easy thing to do, but you neglected to mention expression safety, which is equally important. That a vertex wants T is trivial. That the underlying expression wants a T with very specific properties is decidedly non-trivial. Additional remarks: >> You should only be able to connect vertices (i.e. functions) when their argument/value types are compatible. This also doesn't handle type conversion, which can be exceedingly complicated in visual programming. Should casting be done by vertices? Should you allow implicit type conversions at the vertices? Should the visual programmer be able to choose? I only ask because it is incredibly tedious and frustrating to work with data flow computation tools that say they make things easier, but then have all these super strict requirements about what can be plugged into a particular vertex. Strictness MURDERS expressiveness, and programmers LOVE text because it's super fucking expressive! >> You can keep the language design simple. You don't need special constructs for things like iteration and conditionals. Yes, ideally, you can keep things simple, but you will need to address things like iteration, recursion, and conditionals. Here's why: the REALLY hard part about visual programming is determining how to strike the right balance between the 50,000 foot view and the microscopic view. Many programmers complain (rightly) about visual programming because they feel stuck at the 50,000 foot view and it's incredibly frustrating. On the other hand, doing iteration and recursion with visual programming tools is often very painful. I'll write a bit more about why. To this point, you could make everything work with functions -a 50,000 foot view- but this quickly becomes very inconvenient because it makes it incredibly tedious to solve many types of problems. You'll be forever wrapping things up and trying to decide on the right function boundaries or how large (or small) to make a particular chunk of computation. So then you go ahead and do iteration and recursion. Now your simple vertex-edge design might need a stack, or at the very least, it might need to understand that parts of its computations aren't going to be directly represented by the data flow graph. Now we run into some interesting problems that we can explore using notions from abstract algebra. A data flow graph works best when every element of computation is represented directly in the graph. But if we're using iteration and recursion (using them to prevent us from being inconveniently locked in to a 50,000 foot view of our problem space) then our data flow graph is no longer closed. Problems arise because important (critical) algebraic axioms are no longer satisfied. By closed, I mean that there are elements of computation that are outside the set of data flow nodes (here, the word 'set' refers to the data flow nodes from a set-theoretic perspective). The initial conditions of a for() loop (the initialization expression, condition expression, and loop expression) are represented in the data flow graph, but there aren't any data flow nodes for any subsequent iterations. Since this is the case, how would the user work with them? What about iteration that doesn't use for() loops? Those are much easier, but it doesn't solve the incredibly difficult problems that arise when the data flow graph does not contain all the elements of computation. With our loop situation, we have to look at a very common use case with respect to loops. Often in a loop you'll do some work, but you might also write a value to an unrelated variable or object that you're going to use later. Right? You might initialize something at a particular point in a loop assuming a particular condition is true or false or if the loop counter is a certain value. Since all those loop iterations -elements of computation- are not in the graph, how would you allow a programmer to capture a value during loop execution? This might seem like a nitpick or corner case, but it certainly is not, and these kinds of shortcomings are exactly what programmers mean when they say they don't like visual programming. These are some of the most seriously difficult parts of representing computation with data flow graphs. * I hope you'll post on HN when you have something complete!
yorwba 9y ago
> What if the input is the right type, but doesn't have the right count for the expression? That just means that your type system isn't powerful enough to talk about counts. Of course most type system that can do this are probably too complex for untrained users. Maybe this could be mitigated by providing simple counterexamples for each type error. (Actually, if someone knows about research into understandable error messages for type systems, I'd appreciate a link.) Alternatively, you could use a simpler type system to just narrow down possible connections (maybe highlight endpoints of the correct type when dragging) and leave the rest to be handled at runtime. > 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). I think just having a node labeled with operations defined using a wizard would be a pretty poor use of visual programming. For data selection, I think the node should represent the data directly (e.g. when it's the content of a form, the node should look just like the form), and connections should be made directly to individual fields instead of requiring dedicated selection nodes. To be sure, that won't work as easily for variable sized collections, and objects with lots of fields will clutter up the program; but you can always use the tedious way for those. > 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. There are ways to avoid that, e.g. by allowing multiple nodes for each variable (similar to ports in circuit diagrams) that can be placed closer to where the variable is used. That does mean you can't follow the connections from the variable to all usage sites, but is closer to the way textual programming works. Disclaimer: I have almost no experience with visual programming, and I have been moving to using the keyboard for more stuff lately (i3 window manager, Vimium in Firefox, ...) so I'm almost certainly not in the target demographic for visual programming.
- biocomputation 9y ago
  You have good comments. << To be sure, that won't work as easily for variable sized collections In another response here I discuss the problems with iterations and notions of algebraic closure. Your remarks about 'variable sized collections' are exactly the sorts of problems that arise when your data flow language can't/doesn't directly represent all the elements of computation. When that happens, things either 'leak out' of the data flow diagram, or they remain locked inside impenetrable abstractions. Both of these problems broadly underline a lot of the complaints that programmers have about visual programming tools/languages. Stated simply, the complaints are: "I can't declare a loop/recursion in this visual programming language. This sucks!" Or: "Implementing loops in visual programming sucks because I can implement the loop/recursion, but there's no debugger/stack so I can't inspect the loop/recursion at a particular iteration step/stack frame. This sucks!"

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.

biocomputation 9y ago
> What if the input is the right type, but doesn't have the right count for the expression? Let's say you have type T. T stores one or more pictures. Let's say you have a vertex in the vertex-edge graph that wants an input of type T, but it also wants a T that stores a specific number of pictures. You can ensure basic type safety by requiring an input T for the vertex, but you cannot ensure expression safety since T satisfies the type safety requirement, but not the requirements of the expression represented by the vertex. In your initial remarks, you mentioned type safety as a relatively easy thing to do, but you neglected to mention expression safety, which is equally important. That a vertex wants T is trivial. That the underlying expression wants a T with very specific properties is decidedly non-trivial. Additional remarks: >> You should only be able to connect vertices (i.e. functions) when their argument/value types are compatible. This also doesn't handle type conversion, which can be exceedingly complicated in visual programming. Should casting be done by vertices? Should you allow implicit type conversions at the vertices? Should the visual programmer be able to choose? I only ask because it is incredibly tedious and frustrating to work with data flow computation tools that say they make things easier, but then have all these super strict requirements about what can be plugged into a particular vertex. Strictness MURDERS expressiveness, and programmers LOVE text because it's super fucking expressive! >> You can keep the language design simple. You don't need special constructs for things like iteration and conditionals. Yes, ideally, you can keep things simple, but you will need to address things like iteration, recursion, and conditionals. Here's why: the REALLY hard part about visual programming is determining how to strike the right balance between the 50,000 foot view and the microscopic view. Many programmers complain (rightly) about visual programming because they feel stuck at the 50,000 foot view and it's incredibly frustrating. On the other hand, doing iteration and recursion with visual programming tools is often very painful. I'll write a bit more about why. To this point, you could make everything work with functions -a 50,000 foot view- but this quickly becomes very inconvenient because it makes it incredibly tedious to solve many types of problems. You'll be forever wrapping things up and trying to decide on the right function boundaries or how large (or small) to make a particular chunk of computation. So then you go ahead and do iteration and recursion. Now your simple vertex-edge design might need a stack, or at the very least, it might need to understand that parts of its computations aren't going to be directly represented by the data flow graph. Now we run into some interesting problems that we can explore using notions from abstract algebra. A data flow graph works best when every element of computation is represented directly in the graph. But if we're using iteration and recursion (using them to prevent us from being inconveniently locked in to a 50,000 foot view of our problem space) then our data flow graph is no longer closed. Problems arise because important (critical) algebraic axioms are no longer satisfied. By closed, I mean that there are elements of computation that are outside the set of data flow nodes (here, the word 'set' refers to the data flow nodes from a set-theoretic perspective). The initial conditions of a for() loop (the initialization expression, condition expression, and loop expression) are represented in the data flow graph, but there aren't any data flow nodes for any subsequent iterations. Since this is the case, how would the user work with them? What about iteration that doesn't use for() loops? Those are much easier, but it doesn't solve the incredibly difficult problems that arise when the data flow graph does not contain all the elements of computation. With our loop situation, we have to look at a very common use case with respect to loops. Often in a loop you'll do some work, but you might also write a value to an unrelated variable or object that you're going to use later. Right? You might initialize something at a particular point in a loop assuming a particular condition is true or false or if the loop counter is a certain value. Since all those loop iterations -elements of computation- are not in the graph, how would you allow a programmer to capture a value during loop execution? This might seem like a nitpick or corner case, but it certainly is not, and these kinds of shortcomings are exactly what programmers mean when they say they don't like visual programming. These are some of the most seriously difficult parts of representing computation with data flow graphs. * I hope you'll post on HN when you have something complete!

yorwba 9y ago

> What if the input is the right type, but doesn't have the right count for the expression? That just means that your type system isn't powerful enough to talk about counts. Of course most type system that can do this are probably too complex for untrained users. Maybe this could be mitigated by providing simple counterexamples for each type error. (Actually, if someone knows about research into understandable error messages for type systems, I'd appreciate a link.) Alternatively, you could use a simpler type system to just narrow down possible connections (maybe highlight endpoints of the correct type when dragging) and leave the rest to be handled at runtime. > 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). I think just having a node labeled with operations defined using a wizard would be a pretty poor use of visual programming. For data selection, I think the node should represent the data directly (e.g. when it's the content of a form, the node should look just like the form), and connections should be made directly to individual fields instead of requiring dedicated selection nodes. To be sure, that won't work as easily for variable sized collections, and objects with lots of fields will clutter up the program; but you can always use the tedious way for those. > 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. There are ways to avoid that, e.g. by allowing multiple nodes for each variable (similar to ports in circuit diagrams) that can be placed closer to where the variable is used. That does mean you can't follow the connections from the variable to all usage sites, but is closer to the way textual programming works. Disclaimer: I have almost no experience with visual programming, and I have been moving to using the keyboard for more stuff lately (i3 window manager, Vimium in Firefox, ...) so I'm almost certainly not in the target demographic for visual programming.

biocomputation 9y ago
You have good comments. << To be sure, that won't work as easily for variable sized collections In another response here I discuss the problems with iterations and notions of algebraic closure. Your remarks about 'variable sized collections' are exactly the sorts of problems that arise when your data flow language can't/doesn't directly represent all the elements of computation. When that happens, things either 'leak out' of the data flow diagram, or they remain locked inside impenetrable abstractions. Both of these problems broadly underline a lot of the complaints that programmers have about visual programming tools/languages. Stated simply, the complaints are: "I can't declare a loop/recursion in this visual programming language. This sucks!" Or: "Implementing loops in visual programming sucks because I can implement the loop/recursion, but there's no debugger/stack so I can't inspect the loop/recursion at a particular iteration step/stack frame. This sucks!"