> it also wants a T that stores a specific number of pictures. With dependent typing, not only can you specify the size of structures such as arrays and lists,

> it also wants a T that stores a specific number of pictures. With dependent typing, not only can you specify the size of structures such as arrays and lists, the type system has access to those properties at run time even in dynamically created structures, so when you extract an element by position, you have to index by the correct integer ranges instead of using unbounded integers. Type safety is anything but easy, but it's obviously the right thing in visual dataflow. Type conversion by casting is unsafe and unnecessary. If you want to add a list of numbers, you have supply a list of numbers, or a list with untyped elements, and then the type system decides your list can only contain numbers. If you want to read numeric values from a list of strings and add them, you need to convert the strings to numbers first - a function call instead of a cast. Iteration and recursion are painful if your language doesn't have a good way of doing them. The approach I took was to have the simplest one (the feedback loop) as a base and see what can be developed naturally from that, instead of having a special loop construct. This is completely general, and there are examples throughout the tutorial. The lesson on macros, in which iteration is extracted away, hints at how to make iteration less painful. There's a good reason why I wrote an interpreter first: to iron out problems with function calls, functional arguments, iteration and recursion. All the data values are tagged. There are queues at each vertex input instead of a global stack. So the underlying machine is dataflow. If you like, you can give a simple example (in Lisp, C, Java, or Python) of something you think cannot be encoded in my language and I'll see what I can do.