I feel like this only adds complexity to code.
Unit: A visual programming system [video]
21–30 of 41 posts
Re: Unit: A visual programming system [video]
#22I feel like this only adds complexity to code.
We add complexity all the time. In the end it comes down to whether it's worth it.
Re: Unit: A visual programming system [video]
#23Interesting, and clearly a lot of work's gone into this (60,000 lines of Typescript), particularly the UI, which is impressive (if, sometimes, over the top). I've been developing a similar system ( http://www.fmjlang.co.uk/fmj/tutorials/TOC.html ) and it's interesting to note the similarities and differences. Similarities: code as directed graphs (less obvious in FMJ); can only connect outputs to units of compatible…
> 2) I’ve thought about this problem a lot. Like to a very unhealthy degree… To the extent that I’ve been working on a visual dvcs full time for over a year, that interops visual programming tools with textual codebases that use textual version control. When you say you solved this, is it because you expect users of your tool to be able to understand and reason about however you’re storing your state to disk? Xcode does this with the infamous project.pbxproj and it still causes immense merge conflict pain to this very day (and it’s one file), on the other end of the spectrum, large game studios have basically forgone dvcs to use shader editors at scale. If your language tool is simple enough to reason about textually, doesn’t that limit the utility of your language? I don’t mean in the sense that you make it deliberately hard to reason about your ast equivalent but presumably it wouldn’t take much complexity before a bad merge conflict could break relations and make malformed states. How do you handle that without writing a hand rolled merge driver for each vcs you support?
In my humble opinion this is kind of the breaking point of almost all higher order programming tools. I think it’s also the reason most “no-code” or “design-to-code” tools feel like a sham to engineers. I’d love to hear how you overcame merge conflicts for your tool, I’m skeptical, but I’m all ears.
Re: Unit: A visual programming system [video]
#24Interesting, and clearly a lot of work's gone into this (60,000 lines of Typescript), particularly the UI, which is impressive (if, sometimes, over the top). I've been developing a similar system ( http://www.fmjlang.co.uk/fmj/tutorials/TOC.html ) and it's interesting to note the similarities and differences. Similarities: code as directed graphs (less obvious in FMJ); can only connect outputs to units of compatible…
> 2) I’ve thought about this problem a lot. Like to a very unhealthy degree… To the extent that I’ve been working on a visual dvcs full time for over a year, that interops visual programming tools with textual codebases that use textual version control. When you say you solved this, is it because you expect users of your tool to be able to understand and reason about however you’re storing your state to disk? Xcode d…
It's low level, but still readable and, if necessary, editable. The problem I had was converting my visual code into a topologically sorted directed acyclic graph, with just vertices and arcs, where the arcs into and out of vertices are unordered. I found a way of doing this (thereby getting homoiconicity for free) and now can just store the textual representation of the graph, with each vertex on a separate line. I'm in the process of replacing the earlier representation, where I just stored lists of objects in an ad-hoc fashion. This works for pure dataflow programs or anything else which is equivalent to a DAG, but would not for e.g. LabVIEW.
Re: Unit: A visual programming system [video]
#25Earlier quoted context omitted.
> 2) I’ve thought about this problem a lot. Like to a very unhealthy degree… To the extent that I’ve been working on a visual dvcs full time for over a year, that interops visual programming tools with textual codebases that use textual version control. When you say you solved this, is it because you expect users of your tool to be able to understand and reason about however you’re storing your state to disk? Xcode d…
It's low level, but still readable and, if necessary, editable. The problem I had was converting my visual code into a topologically sorted directed acyclic graph, with just vertices and arcs, where the arcs into and out of vertices are unordered. I found a way of doing this (thereby getting homoiconicity for free) and now can just store the textual representation of the graph, with each vertex on a separate line. I'…
That’s interesting to hear and I think I arrived at a similar homiconic IR state for my tool too. I think there are some problems you might run into if you’re doing any sort of relational cascading but this sounds sane and like a good approach. Thank you for sharing!
Re: Unit: A visual programming system [video]
#26Things like this have been done many times before. Houdini lets you create shaders with node graphs and plenty of other programs have done the same thing. It has a lot of advantages in that more constrained space.
The problems are always the same but I think they aren't clear until someone has already gone down this road.
1. Building expressions out of nodes is much less information dense that just typing them out. What would be a single line of text can end up being a lot of nodes and taking up a lot of screen space.
2. Expression ordering isn't as clear, since it is a graph of dependencies and to figure out what runs when you have to keep tracing dependencies backwards.
3. Branching is tricky for the same reason. A graph of dependencies makes branching much less clear due to order and a scrambled graph of nodes.
4. Loops are more difficult because they also depend on the order of execution and graphs can make that difficult to decipher and difficult to illustrate.
5. State becomes difficult because you need ordering and it depends on external dependencies.
A lot of graph problems can be seen in haskell too. You have something that works very well when what you are doing is all a series of transformations, but there are large chunks of programming that don't fit in to this model.
Re: Unit: A visual programming system [video]
#27Reminds me LabView
Which for me begs the question, is LabView worth it? It's the only widely used Visual Programming Language I can think of.
Every time someone posts a visual programming language prototype the same claims are made over and over again. Like; adds too much complexity, throws out benefits of text editing, eats up too much screen space etc etc.
I'm convinced that many of those issues can be overcome and that until we figure out how to overcome them I'd like to understand which niches Visual programming really makes sense until then.
If LabView makes sense and is worth it, there ought to be more applications where it makes sense!
Re: Unit: A visual programming system [video]
#28I think the name might be a problem. not really distinguishable especially in programming, hard to google.
Hard to google C and Go but it didn't seem to hurt those languages.
As a counterexample few people know about the programming language called "the" (pronounced "T-H-eh"). It was the first language that had shared pointers, trinary coroutines (where the same thread jumps between three different parts of the code), and a constrain solver in the compiler for resolving the ambiguous multiple base class problem.
Re: Unit: A visual programming system [video]
#29Thanks for sharing. Definitely interesting! I have a number of thoughts on this area. * We need Graph paging: Nodal editors have too much data to present for large systems. Navigating/panning/scrolling a large screen of data is painful. I started writing a C parser (completely incomplete) with the desire to render simple diagrams for the Postgres codebase. But you know that the diagram would be too large to present e…
[deleted]
Re: Unit: A visual programming system [video]
#30Things like this have been done many times before. Houdini lets you create shaders with node graphs and plenty of other programs have done the same thing. It has a lot of advantages in that more constrained space. The problems are always the same but I think they aren't clear until someone has already gone down this road. 1. Building expressions out of nodes is much less information dense that just typing them out. W…
1) Agreed. I wish more of these systems had code nodes that you can just write expressions in. Sadly the big contenders are tuning for a subset of functionality so expression nodes are often an after thought or a mismatch because the graph system doesn't mix with the compiled language underneath.
2) I think this is both unsolvable but can be mitigated with more tooling. The advantage of the graph systems is exactly because they are non-linear. But code is easier to read and understand linearly. I hope one of these graph systems adds an "unrolled" debug view. It would be nice to read the execution of the past n nodes linearly in a transient visual log. The common "highlighted path" view is good but incomplete.
3) I disagree. We're all just used to doing the scoping passively when reading functions. I think the explicit scoping of the dependency graph is often much more clear. Buuut... the explicit graphs edges make branches tedious as you have duplicated dependencies drawn all through the branch. Perhaps a branch paradigm where the many deps enter the branch node and are then forwarded to the branches or even some kind of implicit scoping would make this better.
4) Yes, loops are a challenge because of the common UX used. The hot path highlighting falls apart when you loop over the same set of nodes. Again, an unrolled view might be useful. There's also the concept of dropping some loop types and focusing on for-each and batch/collection processing. I think passing lists or iterating over them solves some of the loop issues. ...buuuttt, many graph systems don't seamlessly handle both lists and single items. Maybe some Lisp influence would help. Graph systems could use something as simple and easy as mapcar.
5) I don't know...most graph systems I've played with had an easier grasp of state because dependencies were so clear. Still, many graphs I see resort to graph scope and global scope. Would be interesting to see state scoped to some group of nodes.