LabVIEW
Flat Sequence Structure
@Andrey_Dmitriev wrote:
Hmmm... Compared to natural languages, for example, egyptian hieroglyphs could be written vertically, (and, by the way, right to left as well). So, we can turn code into kind of art work:
Does that actually spell "do not use" in hieroglyphs?
The current AI language models don't include hieroglyphs...
But Simplified Chinees would be an option: 请勿使用 (do not use)
Search LabVIEW like a graph! 
wiebe@CARYA wrote:
@Andrey_Dmitriev wrote:
Hmmm... Compared to natural languages, for example, egyptian hieroglyphs could be written vertically, (and, by the way, right to left as well). So, we can turn code into kind of art work:Does that actually spell "do not use" in hieroglyphs?
It was just "addon" to "Don't vote" message, and hieroglyphs just taken from alphabet.
But you're right, probably makes sense to add something meaningful here, for example to add "japanese note":
But I'm not sure if this "Haiku" will follow traditional 5-7-5 pattern, my linguistic skills are very limited.
On the other hand, personally I don't see much problems with sequences if they used "properly", like measurement of execution time of the piece of code, or may be for "logical" code organization. In NI Vision's examples I have seen lot of sequences, both Flat and Stacked.
First two examples from Example Finder — Calibrate stereo vision with four stacked frames:
or Compute Depth Image with Flat Sequence (which is over 3000 pixels wide, by the way):
But in general with Dataflow paradigm we can avoid sequences and locals at all, that is true.
AFAIK, NI Vision is scripted code.
Sequence structures are great for that.
I guess if you've been around, it's pretty easy to avoid the need for sequence structures, and if you do use an occasional sequence structure you simply don't tell anyone 😉.
There are these kind if topics in many fields. For instance, in painting there's a 'rule' to never use pure white (or black). There are tons of successful professionals using pure white, but they leaned to use it properly..
So, on topic, perhaps OP can explain the use case?
The OP wasn't really clear, but if we already have a FSS with more than one frame, adding a frame in the down direction would would be ambiguous in the frame ordering. Does he want a Mondrian style grid of frames?
Yes, there are a (very) few use cases for sequence structures (I even have exactly one for a stacked sequence!), but the abuse cases often have roots in the linear thinking of text programs where code executes line-by-line. The thought process is often "I need to do A, then B, then C (which depends on A and B)", while the correct thinking would be "I need to do A and B in any order or even in parallel before I can do C".
Once we overuse sequence structures, the compiler gets shackled and is prevented from doing many optimizations that would otherwise offer great performance improvements.
@altenbach wrote:
The OP wasn't really clear, but if we already have a FSS with more than one frame, adding a frame in the down direction would would be ambiguous in the frame ordering. Does he want a Mondrian style grid of frames?
If both horizontal and vertical frames are allowed, it would allow folding up like a cube:
Nice for circular buffers? Or infinite state machines?
wiebe@CARYA wrote:
Nice for circular buffers? Or infinite state machines?
Maybe we would need a "sequence loop" 😄
@LVNinja wrote:As a rule of thumb if the diagram gets too big, then it's time to think on a subvi.
I personally think that iff something is a sequence of code, it's better to show it as a sequence of code, not a sequence of SubVIs. At least not if the SubVIs serve no other purpose than to hide code.
So, I avoid code that doesn't, but if it's a bit wider OR higher, I'm ok with that iff it's the nature of the code.
Wide code is typical for e.g reporting. Add this, add that, add x, add y, etc. Often reuse makes does make sense, and it becomes add(this), add(that), add(x), add(y), but if there's no reuse, I just put it on one wide screen... Hiding code isn't always an improvement.
@altenbach wrote:
wiebe@CARYA wrote:
Nice for circular buffers? Or infinite state machines?
Maybe we would need a "sequence loop" 😄
I do see opportunities here:
wiebe@CARYA wrote:
@LVNinja wrote:As a rule of thumb if the diagram gets too big, then it's time to think on a subvi.
I personally think that iff something is a sequence of code, it's better to show it as a sequence of code, not a sequence of SubVIs. At least not if the SubVIs serve no other purpose than to hide code.
So, I avoid code that doesn't, but if it's a bit wider OR higher, I'm ok with that iff it's the nature of the code.
Wide code is typical for e.g reporting. Add this, add that, add x, add y, etc. Often reuse makes does make sense, and it becomes add(this), add(that), add(x), add(y), but if there's no reuse, I just put it on one wide screen... Hiding code isn't always an improvement.
I try to do "one function, one VI". This makes it very easy to troubleshoot and very easy to follow the code at a top level. A subVI doesn't have to exist solely for code reuse. I normally don't feel the urge to make a subVI because something takes up too much room simply because it never gets that bad. Come to think of it, this actually has something to do with the original topic because I will make a one frame sequence structure, connect wires to it and then make a subVI out of it to give me an initial template to start with. (I then get rid of the sequence structure inside the subVI I just made.)
I will do that to other people's spaghetti code just to get stuff out of the way, though.
