Very interesting topic for me. Thanks for posting this. As pointed out in other post, it's widely used in audio/music programming. My project Glicol(graph oriented live coding language) joins this list recently:
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:
Flow-based programming is very old. Often in combination with visual programming languages, it has been used for a very long time in automation systems, data and signal processing systems, audio, etc.
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.
> 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.
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.
I take your meaning, but just to nitpick one thing here in your argument: SystemVerilog is commonly used to model an abstract machine which is then synthesized into realizable circuits. Its selling point was compatibility and similarity to C, Verilog, and VHDL, all textual languages because the proprietary processing code was built that way. It doesn’t necessarily have to be this way, but it turned out this way, so logic designers don’t have another realistic option. Combine this with the misconception that HDLs are programming instead of modeling, and you have a setup for confusion.
> It doesn’t necessarily have to be this way, but it turned out this way, so logic designers don’t have another realistic option.
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).
You can program an FPGA in LabVIEW easier and faster than you can with straight toolchains like what Xilinx provides. The problem there is that you're bound to NI's hardware (which is both the pro and con).
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.
Everyone I know who programs LabVIEW programs like the anti-example shown in the article. It's not LabVIEW's fault, you can certainly develop cleanly. The problem is that quick proof-of-concepts developed by non programmers (technicians, scientists) turn into solutions that become unsupportable.
This isn't to say that traditional languages and programming tools offer better solutions to current LabVIEW users, though.
I worked in LabVIEW for close to a decade. I never saw something close to that screenshot. I did see bad LabVIEW programs for sure, and nothing ever met my personal standards. I also saw a Python file that was the entire program with over 10,000 lines and function signatures / argument lists that were 10-30 lines long. Just the signatures / argument lists, not including the actual function body. My introduction to LabVIEW though was people taking it seriously as a programming language. We used Perforce and did code reviews using graphical code review systems. It was actually pretty nice.
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.
Visual programming should be one of many ways of interacting with a codebase. Some software abstractions are inherently quite conducive to a visual representation, such as anything that can be understood as a monoidal category. (Ordinary dataflow is indeed one example of this, but there are others; and even the modeling of dataflow introduces some extra subtlety, which is barely acknowledged in OP) Others, not so much; and a textual representation might both be more compact and ultimately clearer.
The usual algebraic textual representation is, after a fashion, also a visual representation. Compare how 'w § x § y § z' —or '(§ w x y z)' for the lisp weenies— brings together an operation and its arguments in a single visual chunk, to how in RPN there are many ways for the arguments and their operations to be arbitrarily separated in the textual stream.
houdini (3d animation package) can go pretty far with parametric flow based scene descriptions. I really wonder what's the actual scalability problem in other fields.
I used a flow based programming language for 7 years. Scale is not the issue since the nodes can be subflows. So you don't build one gigantic spaghetti bowl of a flow. You build a high level flow with the nodes being subflows. You do that recursively until actually implementing the business logic.
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.
Flow-based programming is "the future" in the same way that Object-oriented programming was "the future" in the late 90s.
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.
This exactly. I am playing around with gpt-3, its trivial to build schemas using natural language, and building functions that interact with those schemas, also with natural language
For Architects, Designers and Musicians, flow-based programming is a big deal: Rhino/Grasshopper, Touchdesigner or Ableton Max for Live are all great examples.
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).
I think the main issue for programmers is VCS, and the associated tooling like diffs. With git + code, you have an easy way to modularize, diff, collaborate and review. In these other professions, you mostly work alone or go through the painful process of working together on the same project.
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.
Do you know vvvv gamma[1][2]? It's a visual programming environment for the .Net ecosystem. It's documents are saved in a XML format and they have build a visual merge / diff tool that works quite well. The strategies it applies are explained in detail in the readme of the repo[3].
This highlights the crux of the issue. The problem is not that visual programs are inherently resistant or impossible to being compared and merged. In fact, because a lot of syntactic and semantic information is built into the representation, it often becomes more clear when doing comparisons. The actual problem is that existing tooling, like Git, are myopic in that they assume all programs should have text-based representations. The problem is that the status quo does not scale to visual programs and not the other way around.
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.
Is the ability to show a non-text-based diff that related to how a source control system works under the hood though?
Sure, a text-based diff tool may use some of the same underlying algorithms to determine what the differing lines are, but I wouldn't assume they have to, and usually have options to do things line ignore case/whitespace/line endings/ formatting or show mid-line (even per character) differences that go beyond how git itself calculates diffs. A top level diff-tool that can proxy out to file-format specific tools would seem to fit well enough into the git toolchain. It's having them integrated into something like bitbucket or github for PR reviews that would be truly powerful.
That's a good point. The issue may simply be one primarily of framing in that text-based diffing and merging tools were not natural, so to speak, but had to be built. And even now, they're not great. I'm constantly irritated by text-based diffing tools because they barely understand anything beyond lines of text. I'm interested to see more semantic diff and merge tools built out.
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.
Definitely solvable! People just got to work on it like they have text-based diffing tools. I'm trying to, but I am slow. For visual languages, the problem mainly lies in graph and constraint algorithms, something I'm trying to come up to speed on.
Even if you know how to code in a general-purpose language, you won't beat the speed of these tools
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.
It's growing in popularity in 3D software. Blender, Cinema 4D, Maya and Vectorworks have added nodes in the last few years. Houdini, SoftImage, Generative Components (Bentley) and Grasshopper were early adopters. nTopology and Modo take a stack approach to parametric modelling. It looks less complicated but you quickly run into their limitations.
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.
Sadly, Godot discontinued their visual scripting recently (which admittedly had a quite low level of abstraction and made some things cumbersome to create).
Interesting to see this come up, as I only recent came across Pure Data [1]. I find it surprising that the numerical programming languages aren't flow-based. R makes good use of pipes, and I guess it works a bit like flow-based programming, except that they are all are 1D segments of variable length, and no branches. Sometimes I think that Go's channels are bit a flow-like (though it is otherwise very much not functional!).
If anyone knows of a flow-based programming add-on to R, I'd be very curious.
Nodered is really awesome. I work in the Salesforce ecosystem where flow based programming is being pushed and adopted and always wish they would have adopted the nodered way of doing things.
+1 suprised it wasnt mentioned. Use it heavily in home assistant to connect up devices that were never designed to talk to each other to do some interesting things.
I used a visual data analytics toolkit for several years to help big telcos reconcile switch vs billing data. The tool was very dated looking, but it was ideal for the specific tasks we were performing.
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.)
A small issue with flow-based programming is that it often doesn't have a good way to represent time and sequencing over "human" time scales - the main project I work on, https://ossia.io combines timeline and dataflow to solve this. It's mainly used by artists but I always wonder about the other potential use cases for it... if anyone has ideas :D
The flow programming is for me at home in integrations. Middleware like Apache Camel, data pipelines like Jaspersoft or workflows like Activiti always offered an IDE with graphical representations of those flows - traditionally a bit kludgy maybe. The newer Ballerina cloud integration language from WSO2 offer this duality code-visual natively.
Why is this comment being downvoted? The nodes of a flow graph (usually) are equivalent to pure functions. The graph represents chaining of those functions and the ports of the nodes are their type signatures.
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...
https://glicol.org
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:
https://github.com/chaosprint/glicol