4 ms·

> I would regularly get asked to do things in LabVIEW that were (sometimes quite literally) impossible to do without writing some C code. Is this because (a) L

> I would regularly get asked to do things in LabVIEW that were (sometimes quite literally) impossible to do without writing some C code. Is this because (a) LabVIEW is high level and C is low level, or (b) because LabVIEW can't handle some complex algorithms? (a) doesn't bother me as using a low-level language for low level tasks is a perfectly reasonable thing to do. > While you can wrap things up in functions and subroutines and etc., you have to know that you should do that. If someone uses a programming language for more than scripting (or in a visual language, sketching) they should learn to program. It makes no difference that the language is visual.

wgerard 9y ago
> Is this because (a) LabVIEW is high level and C is low level, or (b) because LabVIEW can't handle some complex algorithms? It's high-level in the sense that you program by choosing a set of components. A very apt analogy might be Excel and VBA: It would be extremely difficult (if not impossible) to accomplish some tasks using Excel, and if you're using Excel as a "programming language" you will find yourself reaching for VBA to do certain arbitrary tasks. > If someone uses a programming language for more than scripting (or in a visual language, sketching) they should learn to program. It makes no difference that the language is visual. Sure, but saying people should do x is basically absolving yourself of the problem and throwing your hands up in the air. They don't do x, so it's sometimes our job to figure out why they don't x and how we can encourage people to do x over time. LabVIEW is very much presented informally as "program without learning how to program" (very similar to the article), so people using it don't feel as though they should have to learn basic programming fundamentals.
- DonaldFisk 9y ago
  Thanks for your reply. So, in practice (b). I had been led to believe the underlying language G was at least in theory general purpose though its libraries are specific to instrument control and similar applications.
analog31 9y ago
I used LabVIEW for a few years. In my view, LabVIEW is as low level as you want it to be. It has some very low level operators. And it can handle algorithms as complex as you want them to be. One of the first hurdles faced by all beginning programmers is "what to do when a program gets too big to fit on one screen," or to understand in one sitting, etc. We all know at least some basic solutions to this problem: Variable naming, subroutines, etc. When LabVIEW programs grow beyond a single screen, which happens quickly, it becomes very cumbersome to navigate through multiple windows and their different viewing modes. Since a program can have multiple entry points, it's hard to figure out what a program "does" in a top down fashion. Second, there's the reason why so many of us went back to CLI and text editors after experiencing the wonders of the GUI. I think that doing complex work with GUI based tools becomes physically laborious to the point of being debilitating. I came away from my LabVIEW sessions with splitting eyestrain headaches and wrist fatigue. The physical work involved in laying out code also discourages refactoring. Maybe, oh maybe, there's something right about text based programming languages.
- DonaldFisk 9y ago
  Or maybe LabVIEW needs a better editor/IDE. I very quickly gave up with Franz Lisp on a VAX running Berkeley Unix not because of any deficiency in the language but because I had to use vi to edit it. There have been only two languages (Prograph and Max) with any similarity to LabVIEW which have gained significant numbers of users, so the space of visual dataflow languages hasn't been explored enough to write them all off. LabVIEW was designed in the 1980s when nothing similar to base it on existed, and various design choices were committed to which didn't work out well. In the following decades, many advances in language design took place or were widely adopted and would be difficult to retrofit to an language of that era. I've only read about LabVIEW, but I have a fair amount of experience designing another visual dataflow language, Full Metal Jacket (http://web.onetel.com/~hibou/fmj/FMJ.html http://web.onetel.com/~hibou/fmj/FMJ.html). In Full Metal Jacket's IDE, opening a function definition is done by right-clicking on its vertex (rectangle); connecting an output of one vertex to an input of a second vertex by dragging the mouse cursor in its general direction and releasing or, if the the second vertex is absent, right clicking on the output and dragging the vertex from another window. Hovering over a vertex displays its documentation string, hovering over inputs or outputs displays their types. I adopted some ideas from functional programming languages - simple syntax from Lisp along with Gabriel's MIT approach, strong static typing with type inference from Haskell and ML, tagged data and a few other ideas from experimental dataflow hardware (I knew the people involved in this both at Cumbernauld and Manchester); and some vocabulary from graph theory. It was obvious to me very early on that there was no way anyone could honestly market dataflow languages at people who don't consider themselves programmers. Not only do you still need to design algorithms, you have to think in a completely new way.

wgerard 9y ago

> Is this because (a) LabVIEW is high level and C is low level, or (b) because LabVIEW can't handle some complex algorithms? It's high-level in the sense that you program by choosing a set of components. A very apt analogy might be Excel and VBA: It would be extremely difficult (if not impossible) to accomplish some tasks using Excel, and if you're using Excel as a "programming language" you will find yourself reaching for VBA to do certain arbitrary tasks. > If someone uses a programming language for more than scripting (or in a visual language, sketching) they should learn to program. It makes no difference that the language is visual. Sure, but saying people should do x is basically absolving yourself of the problem and throwing your hands up in the air. They don't do x, so it's sometimes our job to figure out why they don't x and how we can encourage people to do x over time. LabVIEW is very much presented informally as "program without learning how to program" (very similar to the article), so people using it don't feel as though they should have to learn basic programming fundamentals.

DonaldFisk 9y ago
Thanks for your reply. So, in practice (b). I had been led to believe the underlying language G was at least in theory general purpose though its libraries are specific to instrument control and similar applications.

analog31 9y ago

I used LabVIEW for a few years. In my view, LabVIEW is as low level as you want it to be. It has some very low level operators. And it can handle algorithms as complex as you want them to be. One of the first hurdles faced by all beginning programmers is "what to do when a program gets too big to fit on one screen," or to understand in one sitting, etc. We all know at least some basic solutions to this problem: Variable naming, subroutines, etc. When LabVIEW programs grow beyond a single screen, which happens quickly, it becomes very cumbersome to navigate through multiple windows and their different viewing modes. Since a program can have multiple entry points, it's hard to figure out what a program "does" in a top down fashion. Second, there's the reason why so many of us went back to CLI and text editors after experiencing the wonders of the GUI. I think that doing complex work with GUI based tools becomes physically laborious to the point of being debilitating. I came away from my LabVIEW sessions with splitting eyestrain headaches and wrist fatigue. The physical work involved in laying out code also discourages refactoring. Maybe, oh maybe, there's something right about text based programming languages.

DonaldFisk 9y ago
Or maybe LabVIEW needs a better editor/IDE. I very quickly gave up with Franz Lisp on a VAX running Berkeley Unix not because of any deficiency in the language but because I had to use vi to edit it. There have been only two languages (Prograph and Max) with any similarity to LabVIEW which have gained significant numbers of users, so the space of visual dataflow languages hasn't been explored enough to write them all off. LabVIEW was designed in the 1980s when nothing similar to base it on existed, and various design choices were committed to which didn't work out well. In the following decades, many advances in language design took place or were widely adopted and would be difficult to retrofit to an language of that era. I've only read about LabVIEW, but I have a fair amount of experience designing another visual dataflow language, Full Metal Jacket (http://web.onetel.com/~hibou/fmj/FMJ.html http://web.onetel.com/~hibou/fmj/FMJ.html). In Full Metal Jacket's IDE, opening a function definition is done by right-clicking on its vertex (rectangle); connecting an output of one vertex to an input of a second vertex by dragging the mouse cursor in its general direction and releasing or, if the the second vertex is absent, right clicking on the output and dragging the vertex from another window. Hovering over a vertex displays its documentation string, hovering over inputs or outputs displays their types. I adopted some ideas from functional programming languages - simple syntax from Lisp along with Gabriel's MIT approach, strong static typing with type inference from Haskell and ML, tagged data and a few other ideas from experimental dataflow hardware (I knew the people involved in this both at Cumbernauld and Manchester); and some vocabulary from graph theory. It was obvious to me very early on that there was no way anyone could honestly market dataflow languages at people who don't consider themselves programmers. Not only do you still need to design algorithms, you have to think in a completely new way.