The state of Flow-based Programming
blog.kodigy.com
blog.kodigy.com
I managed to use solely text based style for denoting audio graph. But often I am asked why I have no visual programming interface for it. I would be happy to listen to all the feedback from you at the repo:
The demo page is stellar: https://glicol.org/demo#ambienthouse
The problem with visual programming languages (the focus of the articles seems to be on them) is that they don't scale in size and complexity. For large projects, you end up with visualizations like the LabView one in the article. For complex projects, you try to tame the complexity by offering a textual language to program complex components, with the consequence that you are constantly switching between the two representations.
I found it to be fantastic for building flows for complex processes. If I asked you to communicate something like a mortgage application process you're probably going to draw me a flow. So it's very natural to program in something that looks like a flow.
The problem is that when you get to the task level it's not really a flow any more. If I asked you to communicate how to make pancakes you'd give me something like a recipe. Programming is similar. When it comes to the nitty gritty of building some algorithm it's easier to do it in text based code.
The problem with flow based programming comes down to that gap. It's hard to bridge from the flow to the algorithm in a way that that is intuitive and with good tooling.
That is not true. (1) No one programs LabVIEW like that, and if they do, then they aren't doing code reviews or taking software development seriously. In fact, the visual 2D nature of LabVIEW is a feature, because it becomes immediately and visually apparent if your code is actual spaghetti or not, as in the meme-like picture that gets posted constantly. Spaghetti code certainly exists in text-based languages, but it is not so readily apparent. (2) I have built large, complex systems with LabVIEW, in fact larger than any text-based program I've worked on in industry. I wish they were publicly available/publishable to show, but they are not, unfortunately. LabVIEW scales well for the same reason that languages like Erlang and Elixir scale well. It has built-in concurrency and multi-threading and the core data types, including its OOP objects, are immutable. When scaling, the issues one comes across do not relate to the visual representation but rather other issues specific to the implementation of the LabVIEW IDE.
You mean it's possible to not program LabVIEW like that. Probably true but in my experience people do make programs like that (though not as extreme). I think that meme is a real program.
In fairness to visual programming I think LabVIEW does give it an unnecessarily bad name purely because it is so damn ugly and unreadable. They didn't have to make everything out of Windows 3.1 16x16px icons and the ugliest line styles you could come up with. Simulink looks way nicer for example.
But I still think they make little sense. Editing them is a huge pain, and adding comments is enough of a pain that nobody does it (I'm generalising; I'm sure you are the rare exception).
I think it's pretty telling that logic designers use SystemVerilog and not some graphical circuit diagram type thing even though they're literally designing circuits.
https://research.ibm.com/haifa/Workshops/verification2004/pa...
I mean, I think if graphical programming were really that compelling another option would have presented itself. People are constantly trying to introduce new graphical programming systems.
> Combine this with the misconception that HDLs are programming instead of modeling
I don't think that's really a misconception unless you have an especially pedantic definition of "programming". As you literally just said, Verilog was originally designed for simulation only - you literally were writing a simulation program.
The act of programming Verilog is not really that different from programming C. The only difference is that the abstract machine your code runs in is very different (for synthesisable code anyway).
But several people are moving to higher-level DSLs, like Chisel. I learned LabVIEW before I learned VHDL. It felt kind of silly learning VHDL when you draw out chips and think about them visually but then have to "compile" them down to VHDL yourself. Mathworks makes visual tools for coding FPGAs as well. I think there's a future for tools that make FPGAs easier to design.
> adding comments is enough of a pain that nobody does it
Interesting. Adding comments is as easy as double-clicking on the diagrams. It's even nice because you can paste in picture comments easily, from presentations, manuals, references, etc.
This isn't to say that traditional languages and programming tools offer better solutions to current LabVIEW users, though.
My main point is that there is nothing inherent to the visual paradigm that causes this. It's mainly a merger of two things: the visual paradigm making it more apparent than text-based programs, and the makeup of people writing the programs. Any language can support a bad programming making all the foot guns they'd like.
The fact that that screenshot keeps appearing tells me it's reposted by people who have never actually worked in LabVIEW. It's just the first thing that comes up when they search for it.
I have some LabVIEW code here: https://github.com/slo-systems. It's just a couple of libraries I developed in my spare time at the moment and not big systems, but it's at least in a step in the direction of what I'd consider good code.
All that to say, can LabVIEW be improved? Yes, in the same way that any language and IDE can be improved. We have a long way to go for software development.
If history is any evidence, in 10 years we will all be using some mix of evented/flow based GUI tool. Some people will complain that everyone else is wrong, the functional programming folks will claim they invented flow-based programming first, and we'll see everything that has been being reinvented every 3 years for the last 20 years reinvented again.
And I look forward to it. This is just the way our industry is - new ideas + young energy crashing against institutional knowledge, slowly advancing the status quo.
More people should pay attention.
Even if you know how to code in a general-purpose language, you won't beat the speed of these tools (for small to medium-sized programs, anyway).
Nodes were popular in compositing software in the 90s - Nuke, Flame, Shake.
Code is better when the programme gets bigger but they're less scary for non-programmers to get into.
It isn't even an either or proposition in general. In grasshopper for example you can just drop in a Python on VB node anywhere in your flow and run arbitrary code before passing the output along. It is also really easy to write your own nodes in C# letting you wrap any arbitrary complex analysis and data transformation using any .Net library you want, into a simple node you (or anyone) can just drop into their own flow-based program.
This shouldn't be impossible for flow-based tools, either by making them collab based (like figma) or by having multiple representations (declarative code and visual - possibly by having visual be read-only).
Flow based programming already have a straightforward and imo excellent path for modularization (which is the only known way to deal with software complexity). I would love to see flow based programming combined with individual components written in conventional languages. Regular code is clearly superior for many tasks, so flow should be applied between components, and not be too granular.
Another challenge is meta-programming. If you need to produce components at runtime, you would naively lose visualization and other benefits. So more research and idioms are needed to really present a coherent system that maintains a similar DX when that extra flexibility is needed.
Still, I'm very bullish on medium-term applications of flow based programming within software design. At least for me, it has some absolute killer features; such as understanding existing systems, mapping to my mental model better and spotting bottlenecks and inconsistencies much earlier. I already use pencil-and-paper flow diagrams for software design, but resort to conventional code when implementing.
[1]https://visualprogramming.net
Thus, visual tooling for comparison is currently bespoke for particular environments, like that of vvvv or LabVIEW, and are usually hampered because of things like Git. There's a reason why game and art studios often use Perforce and Plastic SCM rather than Git, and it's because those studios have comparison needs that do not revolve around pure text.
Regarding source-code control, I think it's a problem mainly of Git and not tools like Perforce or Plastic SCM which handle binary files that change over time better. It's also an issue for things like GitHub, which as far as I know, does not provide any hooks for custom diffs to be viewed in the browser.
If anyone knows of a flow-based programming add-on to R, I'd be very curious.
For example, it can also be used to build chatbots.
I found the best use was as a discovery tool. Often a business would believe it knew its own processes and rules, but with large complex systems (often quite old software, especially on the billing side), it was very difficult for the companies to know if what they believed were the business rules were actually what was happening in their software.
So we would work with the client to visually express these rules, in steps and phases, using visual flow-based development. It was kind of similar to REPL-based programming in that you could drop a node on the canvas, hook it up to a previous output, and run it immediately. Then you could inspect the outputs to see the result. Of course there were also UI features which made it very easy to get various details at a glance, such as number of elements on outputs with additional details on hover (min/max, avg, etc.)
Being visual, it was also easier for non-technical clients to grasp what was going on. It was sort of a bridge language which allowed us to communicate with the client. Often the client would come up to speed with this representation and actually get involved in the building process.
Eventually you have accurately modeled the business process, or at least what the process _should_ be. Then if the numbers coming out aren't right, you do additional analysis to identify the root causes. Then you build some following models which compensate for this to ensure the correct output. Finally, you have a formula of sorts which can then be implemented in other more production/repeatable code.
On average, a client would recover $10 in lost revenue (due to billing errors) for every $1 they spent on our time.
An unexpected side benefit of this process was that new observations could be made which might shape future business decisions. This was especially useful for new business models (such as design and implementation of early in-flight wifi services).
Regarding model/diagram complexity, that was solved in the same way we solve complexity in text-based coding. You just organize details into sub-models, drilling down or stepping out to different views. One complex model might end up with a single node representation within a higher level model. I always wished we could have UI views like this on normal software projects to help in those times where your head gets lots in the complexity of dozens of modules and hundreds or thousands of functions (seeing the forest despite the trees, etc.)
At least in my mind. Hell even a deployment tool would probably fit some of that paradigm.
It would ofc need some work to adapt it and maybe something like Crochet would make more sense but eh
What about Tensorflow and Pytorch?
>What about Tensorflow and Pytorch?
Those are tools for describing, training, and executing neural networks. (I have used both)
There is a comment in parallel that correctly states "getting down" is a gap or difficult. This maps to the fact that functional programming paradigms are easier to use higher up and deep down it somehow gets imperative on the way, and be it only in the compiler...