4 ms·

I work on a graphical (dataflow) programming language called LabVIEW. It is primarily used by scientists and engineers for measurement and automation, but is a

I work on a graphical (dataflow) programming language called LabVIEW. It is primarily used by scientists and engineers for measurement and automation, but is also useful for general purpose problems. The code looks similar to a circuit diagram, where nodes are wired together to form your functions. Various constructs are available, be it loops, conditionals (case structures), etc. It is a very different programming model that takes some getting used to - if you try to program as a C programmer in LabVIEW you'll have poorly written code and will be grossly inefficient to boot. But if you understand the paradigm and use it to its maximum benefit you'll can be very efficient. Asking if it matches the efficiency of C is a difficult question as it ultimately depends on what type of problem you are trying to solve. For instance, if you're looking at performance-critical low-level bit-banging code, I'd choose C over LabVIEW. But if it involves data acquisition, analysis, and display, I'd choose LabVIEW over C. Each language has its own domain that it excels at where its efficiency (and expressiveness) peaks.

barrkel 16y ago
Spreadsheets are also arguably dataflow languages, albeit with single values rather than continuous or streams of discrete values (though this changes when you're using a Solve function, or playing around with scenarios). But they benefit from not being programmed in a visual way - i.e. the expressions are normally textual, even if they are marked up (e.g. referenced cells highlighted) to aid understanding. That is, dataflow orientation is distinct from being visual. I implemented a dataflow-like language for UI binding in a web framework once upon a time, and it worked very well. Changes to domain objects in business rules were reflected on the web front end without explicit effort on the programmer's behalf, other than binding expressions associated with the front end's control layout description. The update responses to front end requests (e.g. button click events) were communicated via minimal AJAX, because the binding knew only to send an update when a calculated value actually changed. But having had all this experience, I would still not recommend using a graphical language for it except for UI control positioning.

barrkel 16y ago

Spreadsheets are also arguably dataflow languages, albeit with single values rather than continuous or streams of discrete values (though this changes when you're using a Solve function, or playing around with scenarios). But they benefit from not being programmed in a visual way - i.e. the expressions are normally textual, even if they are marked up (e.g. referenced cells highlighted) to aid understanding. That is, dataflow orientation is distinct from being visual. I implemented a dataflow-like language for UI binding in a web framework once upon a time, and it worked very well. Changes to domain objects in business rules were reflected on the web front end without explicit effort on the programmer's behalf, other than binding expressions associated with the front end's control layout description. The update responses to front end requests (e.g. button click events) were communicated via minimal AJAX, because the binding knew only to send an update when a calculated value actually changed. But having had all this experience, I would still not recommend using a graphical language for it except for UI control positioning.