4 ms·
Dataflow systems like LabView (https://www.ni.com/labview/ https://www.ni.com/labview/), Starlight Data Engineer (http://www.futurepointsystems.com/ http://www.
by 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 agoA surprisingly large part of computing is about while not (user clicked 'close') do something done
- elblanco 16y agoExactly, 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.