Timeline for Real-time Dataflow Programming
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 3, 2012 at 10:38 | vote | accept | Frank | ||
| Apr 18, 2012 at 6:00 | comment | added | Frank | My question wasn't about diagrammatic languages really, so I'll wait for some other answers for comparison. | |
| Apr 17, 2012 at 18:43 | comment | added | Angelo | @kevincline, it sure can get unwieldy! However, if you stick with the intent of the LabVIEW language and also keep the scope of the project from sprawling, it can be superb for rapid application development in the domains for which it is well-suited. I consider LabVIEW like a very big DSL. | |
| Apr 17, 2012 at 18:34 | comment | added | John R. Strohm | I don't know why RIPPEN was eating me alive shuffling data around between blocks. I only know what the profiler showed me, that 20% of my CPU time was "unaccounted for" in any of the code I was working on. | |
| Apr 17, 2012 at 18:23 | comment | added | kevin cline | The problem with this approach is that as soon as things get interesting, diagrammatic languages become unwieldy. Basically, you can't refactor diagrams. | |
| Apr 17, 2012 at 16:50 | comment | added | Frank | I do not see how data-passing could use up that much CPU in the libraries/concepts I mentioned above. I do not know RIPPEN, but if the problem is not inherent to it, would you mind elaborating a bit on the reasons for these 20%? | |
| Apr 17, 2012 at 13:36 | history | edited | John R. Strohm | CC BY-SA 3.0 |
Correct typo
|
| Apr 17, 2012 at 13:30 | history | answered | John R. Strohm | CC BY-SA 3.0 |