I’m not sure that a few months is enough to understand the true pros and cons of a language. I’m using Elixir in my day job now and have used F# for side projects, and it’s not clear to me any one is faster to program in, especially for GUIs. LabVIEW actually shines, contrary to popular but inexperienced opinion, for large projects. I have used LabVIEW rather extensively, and it seems any project would have seen massive delays if I used something else, which is why I didn’t.
But I can indeed see an argument for strain when using the mouse so much. I have experienced that before and improved my ergonomic setup. As an aside, it is curious to me that many programmers are heavy PC gamers as the one true way to game and don’t complain about the mouse use there but will throw out all sorts of complaints when using it to program or use tools.
> New ideas in graphical software require software intensive effort to try out.
This “problem” isn’t inherent to graphical programming though. It’s because legions of programmers are convinced that text=programming and have spent decades writing text-only tools. You see this friction when using LabVIEW with GitHub, whose tooling is incompatible with the diff and merge tools that come with LabVIEW, which makes GitHub look outdated and not LabVIEW.
I’m actually working on ideas to build a toolkit for graphical programming languages. There are certainly challenges though, such as the desktop GUI ecosystem being a mess and reliance upon graph data structures and algorithms (like automatic layout).
> On the other hand, there does seem to be something about data flow programming (LabVIEW, Excel) that is attractive to beginners
Dataflow is attractive to advanced users as well, which is part of the draw to languages like F#, Elixir, Racket, Clojure, etc. Although, the dataflow in LabVIEW is actually more advanced, which is basically a multithreaded and branched version of the single threaded linear pipelines found in the languages I mentioned. Working in F# and Elixir with pipes can be pretty irritating sometimes given my knowledge of LabVIEW.
I wonder also how using visual languages like LabVIEW compares to other mouse-heavy computer users like photo editors/graphic designers, CAD users etc.
> Dataflow is attractive to advanced users as well
I quite enjoyed using Max/MSP a few years ago when I did some stuff with it for a few months. I've always wished I had it available as a general purpose language in my programming toolbox since. As for other advanced users who use (visual) dataflow, my go to example is Ansys' SCADE Suite[1][2][3], which is used for critical systems like trains, helicopters and power plants.
[1] https://www.ansys.com/products/embedded-software/ansys-scade...
[2] https://www.ansys.com/content/dam/product/embedded-software/...
[3] https://www.youtube.com/watch?v=5z0h-WeScqw&list=PL0lZXwHtV6... (the third video introduces the visual language)
Are those definitely the same people? Mouse use is certainly one of the reasons I gave up gaming. (The other being that an X hour working day is quite enough time to spend in front of a computer already).
I don’t mind visual programming, but I don’t enjoy PC gaming at all. There have been times I’ve experienced fatigue in my mouse hand with consecutive heavy days of LabVIEW programming. I think there are definitely ways to improve it though.
Part of my issue is the reverse shock of what text based programmers experience when moving to a visual language since I’m coming to Elixir from LabVIEW. I missing seeing certain things but am becoming accustomed to it. I’ve done text based programming a decent amount but never day to day on large code bases (and I’m new to Elixir having primarily used F# and Racket for projects and some Python for work against my will).
For tools that require precise placing of wires like LabVIEW and vvvv, mouse strain and also the time it takes is indeed an issue. I am personally interested in sane but beautiful automatic layouts for visual languages, but this is most certainly a difficult problem. For example, if I could make an algorithm that basically makes LabVIEW (or a similar language) reorganize diagrams the way that I do, that would be great.
I think one inspiration are editing bays that professional video editors and also audio professional use. They have heavy use of software intermixed with hardware interfaces to perform their jobs.
It's very simple - if you work with artists and you make them a presentation of your software, and at any moment there is some amount of code displayed on the screen, some of them will get up and leave the presentation.
I worked on my software with someone who would literally refuse to use the keyboard - everything had to be done by mouse, and I know a fair amount of like-minded people in th e same field.
Surprisingly, this is also the case for mechanical engineers. The proportion might be smaller, but they still exist. I know people in freshman classes that are retook the intro to programming class which was stuff like variables, conditionals and loops in Matlab.
Then there's people who did OK in their Fortran classes in the 1990s but never touched a line of cosey since.
The people have a good chance of being intimidated by code. This is where LabVIEW and Simulink come in.
No doubt. My problems were mainly with the ergonomics of the editing environment, not the language. And I had problems with other graphical software as well, including games.
I can totally understand the ergonomics issue. I think that automatic layout is the way to go to reduce pixel-perfect manual layout and thus strain from heavy mouse usage.
Has anyone tried yet, to build a compiler, that compiles code into visual programming structures - and back?
I know scratch does this in a very limited way(code to scratch), but are there other tools around?
I am not aware of any, except for mine (which is unpublished as of yet, but if I get the website right, that might change by this weekend).
Back in 1991 I worked on Labview at a university lab. It seemed amazing for the time.
For a teenager migrating from Basic - Labview seemed a fantastic improvement.
It felt incredibly powerful to draw boxes and wires to make multiple scientific instruments gather data.
I do remember spending a lot of time on alignment, plus there was no code revision at the time...
However, the lab moved to custom C based workflow. It was great on a personal level - writing low level drivers etc.
Part of the reasoning was that at some point the scientists needed a custom UI and it was actually easier to create one with C than with Labview.
I used LabVIEW extensively for a few months, and ended up with crippling wrist fatigue and eyestrain headaches from all of the fine mouse work and menu selections needed to write even small programs. This is an ergonomic problem with all graphical software, but is particularly acute with programming because of the amount of code that gets written.
Another problem is innovation. You can quickly spin up an experimental language and try it out because the infrastructure -- editor and command shell -- already exist. This is one reason why we enjoy such a proliferation of new language ideas. New ideas in graphical software require intensive effort to try out.
On the other hand, there does seem to be something about data flow programming (LabVIEW, Excel) that is attractive to beginners, that can't be overlooked. Excel is probably the number-one programming tool in use right now.