4 ms·

LabVIEW is this way too. I wonder if dataflow programming is more intuitive to non-programmers, even if it might run up against limitations when extended to lar

LabVIEW is this way too. I wonder if dataflow programming is more intuitive to non-programmers, even if it might run up against limitations when extended to larger projects. Both Excel and LV have a reputation of being a way for non programmers to automate complex tasks.

PaulHoule 4y ago
I'm not sure if this is a fundamental problem or just an accident in how these tools have been developed. That is, many dataflow systems have ways you can make systems by drawing boxes (operators) and lines (connections between operators) but don't give you facilities to make a reusable box which is itself comprised of boxes and lines. If somebody really tried to make a tool of that sort which had a modules and other facilities for programming in the large I know we could do better but this may very well drive away the kind of person who is attracted to these tools. (I think of how many "data scientists" react violently to the slightest bit of SE discipline such as separating the results in a Jupyter notebook from the code that generated those results.) It's a shame because all the time data analysts are thinking about "How do I make the monthly sales report for August?" and not about "... for every month" and it is such a universal and predictable problem but the tools don't give people a structured answered. A concept that I've thought about applying to production rules (and maybe other systems) is "rules and schemes" where the code is divided into multiple layers with a relationship similar to HTML and CSS. Logical rules are one thing, what you do with those rules are another thing. People apply this kind of thinking to a small range of concerns in "aspect oriented programming" but with the right kind of compiler support it could be applied to other things like memory allocation. I hear people complain about "colored functions" when doing async programming but when I write for arduino I often write programs where (in my mind) there are a few (say five) colors of function that all play a particular role in the system and I even avoid automatic variables on the stack because they are just a waste in a program of that sort.

PaulHoule 4y ago

I'm not sure if this is a fundamental problem or just an accident in how these tools have been developed. That is, many dataflow systems have ways you can make systems by drawing boxes (operators) and lines (connections between operators) but don't give you facilities to make a reusable box which is itself comprised of boxes and lines. If somebody really tried to make a tool of that sort which had a modules and other facilities for programming in the large I know we could do better but this may very well drive away the kind of person who is attracted to these tools. (I think of how many "data scientists" react violently to the slightest bit of SE discipline such as separating the results in a Jupyter notebook from the code that generated those results.) It's a shame because all the time data analysts are thinking about "How do I make the monthly sales report for August?" and not about "... for every month" and it is such a universal and predictable problem but the tools don't give people a structured answered. A concept that I've thought about applying to production rules (and maybe other systems) is "rules and schemes" where the code is divided into multiple layers with a relationship similar to HTML and CSS. Logical rules are one thing, what you do with those rules are another thing. People apply this kind of thinking to a small range of concerns in "aspect oriented programming" but with the right kind of compiler support it could be applied to other things like memory allocation. I hear people complain about "colored functions" when doing async programming but when I write for arduino I often write programs where (in my mind) there are a few (say five) colors of function that all play a particular role in the system and I even avoid automatic variables on the stack because they are just a waste in a program of that sort.