Many years ago, I spent a fair amount of time coding in LabView. This is a graphical programming environment initially written to allow (presumably electrical) engineers to write code to drive various data acquisition and control tasks. (I'm almost entirely a software guy, so I'm not the target audience.)
The general approach LV takes is to model computation as a data flow graph. Constructions like iteration, selection, etc. are (were?) all modeled as rectangular regions within the graph where portions of a graph can be swapped out for others or run multiple times. Graphs can also be nested to provide a means of abstraction. Execution has gone through changes over the years, but it's efficient: compiled to machine code with LLVM, and there are also versions that compile LV code to run directly on FPGA's (on some of the hardware products sold by the same company). It also takes advantage of the implicit parallelism that sometimes crops up in data flow graphs.
All in all, LV is theoretically quite impressive. (And since it's been sold for I think over thirty years, commercially quite impressive too.)
As a software engineer, though, I never fully acclimated to the way it worked. If laying out textual code is a challenge, laying out a 2D graph is much worse. The same thing goes for defining sub-graphs - 'naming a function' becomes the much worse problem of 'drawing an icon', or maybe even drawing a family of icons with a common theme. (Although I think LV's been extended with a nicer icon editor to help with this.) Input is similarly a challenge... textual tasks that can be split across two hands and ten fingers become focused on a single hand/finger. (I had to rethink my input devices both during and after the time I was using LV to avoid RSI issues.) And there are also issues with source code control. LV has some stuff baked in, but there are many years of industry-wide experience managing textual representations of code and some good tools for doing it. Switching to a different representation for code means, necessarily, deviating from that base of wisdom and practice.
So, while I think it's a powerful tool (and something more engineers should be familar with) it's nothing I'd want to do my daily work in.
I was a sysadmin for a small EE firm that developed test stands with LabView. The biggest common problem I had -- beyond the EEs not having the technical knowledge to understand how networks or operating systems work -- was that source control was a nightmare because everything was a blob.
It made sense to the EEs because they were used to staring at wiring diagrams. I think we'd have a lot more programmers if we could develop similar programming methods that appeal to different ways that people think.
> I think we'd have a lot more programmers if we could develop similar programming methods that appeal to different ways that people think.
I think this is very well put. I occasionally present on programming topics to my sons' classes. Even as early as 8 or 9, programming is well within their intellectual capacity (and often their desires). So programming tools that don't erect huge barriers to entry... maybe lots of latent value.
I use to make a living creating LabVIEW solutions for a few years in manufacturing test applications and in laboratory applications before that.
It works marvelously if you want put together a UI to process measurements from a fairly wide variety of instruments. Someone who is very skilled in LabVIEW can run circles around most expert Python or VB/C# .NET programmers trying the same thing. Seriously it's awesome. You get parallelism "out-of-the-box" with no problem at all. BUT... these benefits only hold true within the problem domains that LabVIEW is good at.
Once you try to use LabVIEW for truly general-purpose tasks it becomes either unwieldy or no better than open-source tools. Eventually, I had to drop LabVIEW when more and more work involved databases, dealing with network protocols, and heavy integration with API's outside of the NI ecosystem. The $3-5K per developer "seat" is also a barrier to entry for some orgs.
I think there's a place for visual programming for certain types of DSL's. Version control, diff'ing, modularization and some of the other things folks are complaining about here are just technical obstacles that can be overcome or worked around with a bit of creativity.
> The $3-5K per developer "seat" is also a barrier to entry for some orgs.
Agreed. In a world where so many good developer tools are essentially free of charge, this aspect shouldn't be overlooked. Neither should the fact that it's fundamentally a proprietary language offered by a single vendor.
As someone who is part of the target audience of LV, every experience I've had with the software have been terrible. I guess it's mostly aimed at industrial automation applications, but the development environment is buggy and coding with rectangular regions gets old fast.
I anecdotally see people moving towards Matlab and Python for automation these days, though its harder without the incredible amount hardware support provided by NI
> I anecdotally see people moving towards Matlab and Python for automation these days,
For a while, NI provided tools in that space too. There was a product called LabWindows, which was centered around C, and a product called Hi-Q that I remember as being similar to Matlab. I assume that the non-LabView story these days is mostly a public API combined with other people's development tools. (At least that's what I'd hope it would be, given the expense of developing programming langauge tooling.)
> though its harder without the incredible amount hardware support provided by NI
Agreed... the hardware offerings are rather amazing and growing every day (even into some fairly specialized and high-end domains).
I had a very similar experience using SCADE. Especially the trouble with version control put me off. That made it basically impossible for multiple engineers to work at the same time on a SCADE project. It also made code review much harder: you'd have to visually diff the rendering.
The general approach LV takes is to model computation as a data flow graph. Constructions like iteration, selection, etc. are (were?) all modeled as rectangular regions within the graph where portions of a graph can be swapped out for others or run multiple times. Graphs can also be nested to provide a means of abstraction. Execution has gone through changes over the years, but it's efficient: compiled to machine code with LLVM, and there are also versions that compile LV code to run directly on FPGA's (on some of the hardware products sold by the same company). It also takes advantage of the implicit parallelism that sometimes crops up in data flow graphs.
All in all, LV is theoretically quite impressive. (And since it's been sold for I think over thirty years, commercially quite impressive too.)
As a software engineer, though, I never fully acclimated to the way it worked. If laying out textual code is a challenge, laying out a 2D graph is much worse. The same thing goes for defining sub-graphs - 'naming a function' becomes the much worse problem of 'drawing an icon', or maybe even drawing a family of icons with a common theme. (Although I think LV's been extended with a nicer icon editor to help with this.) Input is similarly a challenge... textual tasks that can be split across two hands and ten fingers become focused on a single hand/finger. (I had to rethink my input devices both during and after the time I was using LV to avoid RSI issues.) And there are also issues with source code control. LV has some stuff baked in, but there are many years of industry-wide experience managing textual representations of code and some good tools for doing it. Switching to a different representation for code means, necessarily, deviating from that base of wisdom and practice.
So, while I think it's a powerful tool (and something more engineers should be familar with) it's nothing I'd want to do my daily work in.