4.17 Application in Visual Programming
It would be possible to use stress-flow in limited fashion only as means for better internal implementation of prior art visual programming systems. Each specific building block in a prior art visual programming system could “hard-code” its internals to correspond to one particular method described here. For example, all building block outputs could be forced to be “ordered” connectors. This would already produce a superior internal implementation of the prior art systems by decentralizing operations, allowing actual real auto-scaling parallelism, and eliminating the node execution supervisory code. This way, the performance would be greatly improved without changing user interface, but at the cost of limiting application of such systems. Visual programming using the stress-flow concept of stress-flow can however do far more than that.
The key problem with prior art systems is that they could not smoothly transition from constrained or sequential execution to unconstrained parallel or to dataflow model and back when it was required. Commonly used script languages could not do dataflow at all while popular visual dataflow-proclaimed languages did it in a way that strictly separated code into blocks of sequential code that were executed by higher level centralized code which was fairly inefficient and as shown in previous paragraphs actually prevented true parallelism. This was necessary in prior art because non dataflow portions are actually always necessary for all but few very specific programming problems. Key advantage of stress-flow is that it that this limitation is non existent as the stress-flow model uses atomic layer of abstraction that can describe both sequential and data-flow execution model and smoothly transition between the two. This not only allows real parallelism but also totally new unexplored avenues for visual programming.
It is often suspected that visual programming does not get as much use as it should. Programming, of course, had to start as text based because of limitations of original computer hardware. These limitations definitively no longer exist, yet most professional programming is still done in text form. Visual programming was introduced with great pain where it was really unavoidable – for example for designing dialog boxes, human form interfaces, or instrument interfaces in control/instrumentation markets. However, in spite of huge effort toward developing visual programming methods, complex, professional software is still very rarely developed in visual languages. At present time, it would still be quite difficult to even try to propose developing code for an operating system or even a professional word processor in any prior art visual language. If visual software can and is successfully used to develop mechanical systems for very large systems like giant jets or electronics of extremely complex modern computers and processors, there should be no fundamental reason to prevent visual software from being used to develop complex professional software. If a picture can say a thousand words, why shouldn’t a graphical diagram that can use symbols, icons, and colors be a better, more understandable design and representation of software than say 100 lines of code maximum that can be seen at once on the largest commonly used monitor?
In process of developing stress-flow it became obvious that lack of good, versatile, universal parallel programming method was responsible for inability to program complex code visually. As sequential control-flow code is fundamentally one-dimensional, it is unnatural and hard, if not impossible, to represent it graphically in two dimensional space. Visual program can easily split paths into many sub paths and it can merge previously unrelated paths together. Such things are still pretty much heresies or rarely used black-art tricks in the world of sequential control-flow programming where majority of subroutine calls have to return back to the same place they got called from. And this isn’t even a limitation of computer hardware but rather a requirement generated by the way data was stored and accessed, a constraint seemed to be made necessary for data to be managed safely. Stress-flow naturally eliminates these problems. Stress-flow model allows control paths splitting and merging. It allows them to be cloned and allows them to disappear anywhere – exactly what is a graphical diagram describing any actions will naturally look like.
FIG. 28A: Barrier inside visual subroutine as means to represent transition from stressed to relaxed state
FIG. 28B: Special symbol on control line inside visual subroutine as means to represent transition from stressed to relaxed state
Any interface of previous art visual programming methods can be adapted to take advantage of stress-flow, although internal workings of generated code will be completely different. Key new element of such adaptation will be a representation of transitioning from stressed to relaxed code. This can be done by means of special barrier or symbol on control line being crossed. The first method is shown on FIG. 28A where some visual programming subroutine containing two operations Oper A and Oper B uses a separation barrier between stressed and relaxed parts of visual subroutine. The second method is shown on FIG. 28B where a symbol placed on control line indicates transitioning from stressed to relaxed part.
Full utilization of stress-flow might also have special visual symbols to represent ordered, last only, and redundant calls; collectors, etc.
Send mail to
firstname.lastname@example.org with questions or