3 ms·

What is everyone's opinion of LabView. Clearly it was never designed as a server-side language, but it has a very not "linear" approach to designing. I used to

What is everyone's opinion of LabView. Clearly it was never designed as a server-side language, but it has a very not "linear" approach to designing. I used to mock LabView (arguing speed and complexity), but now that I work with a colleague that exclusively uses it--we are a medical research engineering group--I really start to respect its utility. So the question becomes: Would an opensource cross platform scripting language, modeled after LabView, fit this bill?

elblanco 16y ago
Dataflow systems like LabView (https://www.ni.com/labview/ https://www.ni.com/labview/), Starlight Data Engineer (http://www.futurepointsystems.com/ http://www.futurepointsystems.com/) and the Data Model subsystem of ArcGIS can be massively useful for a very large class of problems. However, they tend to fall down for many general programming paradigms. LabView is probably the furthest along that I know of in attacking more general problems, but ultimately they are designed around building a pipeline: datain->do something->data out. LabView also builds in interesting levels of instrumentation and interactive components that can make it seem more general purpose like. In that sense, the old UNIX tools (simple, single function tools you can pipe together to create complex systems) are the same thing. But there are other graphical programming environments that aren't focused around pure dataflow. http://scratch.mit.edu/ http://scratch.mit.edu/ Is actually a very interesting experiment in using graphical components to build up a program. But ultimately it's just a nice wrapper around a regular old programming language, and in playing with it a bit, I found that it was simply faster to just type things in a regular old language. One of the more interesting things about graphical programming systems, is that you can often coax people into learning to use them who otherwise would have no interest or inclination towards writing code. I think there's probably a huge untapped market for a fully graphical system that can compile and perform like native code...
- st0p 16y ago
  [i]datain->do something->data out[/i] Isn't that what computing is all about?
  - fhars 16y ago
    A surprisingly large part of computing is about while not (user clicked 'close') do something done
    - elblanco 16y ago
      Exactly, basing the assumption that computers are only about data in->do something->data out, is a bit of an old-fashioned way of thinking. These days, the vast majority of computation involves execution loops: 1 - Display something (perhaps put some data out) 2 - Receive input 3 - do something (perhaps combine input with data in) 4 - goto 1 This is true of everything from video games to operating systems. Dataflow models are simply a subset of the models of computation we deal with these days...they are extraordinarily useful models, but still limited in what they do.
jules 16y ago
I've used labview and it's awful. It takes hundreds of clicks to get a couple of function calls in place. I'm not saying that something like labview couldn't work well, but the implementation in labview requires far too much clicking work to build a program.
- seltzered 16y ago
  Totally agree, this has made me cry working on any app that has been sustained for years. This is why I think for any "graphical" language approach to be adopted by seasoned programmers should be fully keyboard accessible (think vim, but you can manipulate things across files and objects.
seltzered 16y ago
I've been thinking a lot about this, since I have needed to use LabView at my job the past few years. While I hate labview for the sake of writing applications that need to be continuously refactored and scaled, it's immensely useful for non-programmers to create a working program quickly. So far I've been wondering if a graphical interface a la labview could work if it translated down into say, erlang code. It all depends highly on who the target audience is...a test engineer, or someone wanting an easier way to write scalable distributed applications. If the latter, I'd expect the interface to be a very well thought out interface that lets you effortlessly flow between drilling down into functions and seeing the greater view of all the code in your application.

elblanco 16y ago

Dataflow systems like LabView (https://www.ni.com/labview/ https://www.ni.com/labview/), Starlight Data Engineer (http://www.futurepointsystems.com/ http://www.futurepointsystems.com/) and the Data Model subsystem of ArcGIS can be massively useful for a very large class of problems. However, they tend to fall down for many general programming paradigms. LabView is probably the furthest along that I know of in attacking more general problems, but ultimately they are designed around building a pipeline: datain->do something->data out. LabView also builds in interesting levels of instrumentation and interactive components that can make it seem more general purpose like. In that sense, the old UNIX tools (simple, single function tools you can pipe together to create complex systems) are the same thing. But there are other graphical programming environments that aren't focused around pure dataflow. http://scratch.mit.edu/ http://scratch.mit.edu/ Is actually a very interesting experiment in using graphical components to build up a program. But ultimately it's just a nice wrapper around a regular old programming language, and in playing with it a bit, I found that it was simply faster to just type things in a regular old language. One of the more interesting things about graphical programming systems, is that you can often coax people into learning to use them who otherwise would have no interest or inclination towards writing code. I think there's probably a huge untapped market for a fully graphical system that can compile and perform like native code...

st0p 16y ago
[i]datain->do something->data out[/i] Isn't that what computing is all about?
- fhars 16y ago
  A surprisingly large part of computing is about while not (user clicked 'close') do something done
  - elblanco 16y ago
    Exactly, basing the assumption that computers are only about data in->do something->data out, is a bit of an old-fashioned way of thinking. These days, the vast majority of computation involves execution loops: 1 - Display something (perhaps put some data out) 2 - Receive input 3 - do something (perhaps combine input with data in) 4 - goto 1 This is true of everything from video games to operating systems. Dataflow models are simply a subset of the models of computation we deal with these days...they are extraordinarily useful models, but still limited in what they do.

jules 16y ago

I've used labview and it's awful. It takes hundreds of clicks to get a couple of function calls in place. I'm not saying that something like labview couldn't work well, but the implementation in labview requires far too much clicking work to build a program.

seltzered 16y ago
Totally agree, this has made me cry working on any app that has been sustained for years. This is why I think for any "graphical" language approach to be adopted by seasoned programmers should be fully keyboard accessible (think vim, but you can manipulate things across files and objects.

seltzered 16y ago

I've been thinking a lot about this, since I have needed to use LabView at my job the past few years. While I hate labview for the sake of writing applications that need to be continuously refactored and scaled, it's immensely useful for non-programmers to create a working program quickly. So far I've been wondering if a graphical interface a la labview could work if it translated down into say, erlang code. It all depends highly on who the target audience is...a test engineer, or someone wanting an easier way to write scalable distributed applications. If the latter, I'd expect the interface to be a very well thought out interface that lets you effortlessly flow between drilling down into functions and seeing the greater view of all the code in your application.