LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
SteenSchmidt

Let's get rid of the For-loop, the While-loop, and the Timed loop

Status: New

Hello (again),

 

Well, this idea has haunted me for a couple of years, and now I think it's time to break it. I feel the For-loop, the While-loop, and the Timed loop are so similar that they are begging for a merger. It would simplify, and with a little thought strengthen, the API, to have a single configurable Loop Structure instead. What's the difference between a While-loop and a For-loop with a conditional terminal anyway? Have you ever wished for iteration timing information being available inside your For-loop (I know I have)? "Oh but those structures have been around forever, we can't touch those"... Well, what happened with the stacked sequence structure? Please read on for a minute or two and tell me if I'm losing my marbles here. And please chip in with your own modifiers, since LabVIEW is growing in (sometimes unnecessary) complexity. Thus:

 

CrossedOutLoops.png

 

Instead I propose the Loop Structure which when initially drawn looks like this:

 

NewLoop_Infinite.png

 

The above is basically a loop running forever (don't worry, you can stop it), but it can be modified to do many many other things, just be patient Smiley Happy. One feature of the loop structure is the box in the upper left corner, which is quite similar to what we have in a For-loop today. This will, no matter the configuration of the loop structure, always show the current iteration setting of the structure. By default that is never-ending, but if you drag in a conditinal terminal you change the loop behavior to a While-loop (note that I suggest a simpler way to get to the terminal than via the right-click context menu):

 

NewLoop_While.png

 

Arrays can be wired to the structure border as usual to give a For-loop like behavior. The count terminal changes from "Inf" to an "N" to indicate that it's a finite albeit at edit-time unknown number of iterations:

 

NewLoop_Unknown.png

 

You can wire out of the count terminal inside the loop structure as usual to get the count at run-time of course. If the iteration count can be deducted at edit-time a number will appear instead of the "N":

 

NewLoop_42.png

 

This number is blue to indicate that it is automatically calculated. You can just type in a new number if you wish to run a different number of iterations, in which case all the usual ideas on this Idea Exchange about what should happen to auto-indexed tunnels apply. If you override the count manually the number will be in black text:

 

NewLoop_50.png

 

You can of course combine different exit conditions, in this case a fixed number of iterations with a conditional terminal wired as well for possible early exit:

 

NewLoop_42_Conditional.png

 

The automatically calculated count terminal aids in determining if the loop actually runs the desired number of times:

 

NewLoop_MultipleArrays.png

 

All the usual stuff about tunnels, shift registers and so on apply to this structure as well, but on top of that it can also be configured as you're only used to within a timed loop. Consider how valuable some of these parameters and settings could be for ordinary loops, for error handling and for timing for instance. But the main feat is that this is still the same loop structure - it will simplify the palette a lot:

 

NewLoop_Timed.png

 

And now an additional feature that ties some of the parameters from the timed structure together with ordinary loops: this loop structure is event-enabled! I propose stuff like this (we're only scratching the surface with this image):

 

NewLoop_Events.png

 

It's late where I am now, so I'll stop now, but all of the above makes it extremely easy to do things you simply can't do today - what about a Priority Structure?:

 

NewLoop_PriorityStructure.png

 

So, is it time to consolidate the ever-evolving loop code of LabVIEW into one structure to rule them all? Smiley Very Happy

 

Cheers,

Steen

CLA, CTA, CLED & LabVIEW Champion
40 Comments
Intaris
Proven Zealot

@Intaris & vitoi: So, maybe we could learn to distinguish the loop behavior just be looking at the counter box (or maybe I should call it Behavior terminal)?

 

But that's already more than we need to do now.  Not ov erly terrible, but It's be nice to not sacrifice readability (And speed of reading) versus this nice idea.  Some easier way to differentiate is needed.  Maybe having the multitude of terminaly avalable being shown always on the right top side allowing some common location for investigating the settings.  Just seeing which ones are selected and which ones are grayed out would help some.

 

Like you show here, but with the choices made (visible in your image at the bottom left) permanently visible?

 

vitoi
Active Participant

LabVIEW must be getting pretty mature if we need to discuss "trimmings" such as this. Why change when the outcome is dubious and the transition will be confusing?

 

Let's direct our efforts and attention to some game-changing disruptive innovation, such as LabVIEW targeting everything from microcontrollers to tablets to mobile phones. Now we're talking.

JKSH
Active Participant

+1

 

Elegant, clean, comprehensive, intuitive.

 


@vitoi wrote:

 

LabVIEW must be getting pretty mature if we need to discuss "trimmings" such as this. Why change when the outcome is dubious and the transition will be confusing?

 

Let's direct our efforts and attention to some game-changing disruptive innovation, such as LabVIEW targeting everything from microcontrollers to tablets to mobile phones. Now we're talking.


Why will it be confusing? It's just a new structure to deprecate the others (which will still be around for compatibility, like the stacked sequence structure -- developers aren't forced to make the jump immediately).

 

Also, I believe it is worthwhile to invest in complexity management occasionally (think of this as "refactoring" code). It helps lower the barrier for newcomers.

Certified LabVIEW Developer
vitoi
Active Participant

I think newcomers will find the existing For Loop and While Loop easier to understand than the "Universal" Loop.

 

I'm all for ease of understanding. That is my prime driver in most discussions.

SteenSchmidt
Trusted Enthusiast

I'm all for disruptive innovation. I'd like to see the BD and the FP entirely unrelated for instance. And sure, more platforms would be great, for instance Android (forget about iOS, that's just a fad Smiley Wink).

 

But, this idea probably takes less effort to implement, and I'd really love such an optimization to the existing API. Alternatively I'd really like the following features added to the current structures:

 

- Timing, synchronization, and prioritization added to the For-loop.

- Event-enabling of the For- and While-loops.

- A shallower menu structure to get to the different configuration points of the structures (no more right-clicking and menu fly-out hunting).

- More information about loop-logic readily available in the existing structure space (Not just a static "N" in the For-loop).

 

If some of that's going to happen, it would probably be simpler to just merge those loop structures, wouldn't it? And even if no API changes come of this idea in the next few years, I think the discussion is worth having - some small but very valuable tweaks might pop out of the woodwork while we're talking about it.

 

I'm not suggesting this just because I haven't got any good ideas Smiley Tongue. I really am serious that I think it'd be an improvement. But sure, some programmers fresh out of LabVIEW-school might find it confusing that there is no For-loop and no While-loop. Or, you know what? I think exactly those programmers would be the ones that adapt more quickly. I'm sometimes surprised at how flexible and quick-grasping young techies are today. They many times come totally unshaped by prior expectations, and they are often the first to embrace new ideas and pragmas. It's us old geezers who frown at that new thing called "auto-tool" and such stuff Smiley Very Happy (ok, I have begun using auto-tool, but I'm not on Facebook yet).

 

/Steen

CLA, CTA, CLED & LabVIEW Champion
GregSands
Active Participant

If you're keen on un-relating the BD and FP, you probably should vote for my idea Smiley Happy  I still think this is the best idea I've had, even if it's not very popular Smiley Sad

 

I'm slowly coming around to your point of view on this loopy idea.  I still think it's blurring the distinction between Sequential and Simultaneous iteration, and I worry it could compromise the ability to optimise - particularly parallelised loops.  But I can see that adding new common functionality may be easier with a single structure.  Maybe next week my half-kudo will turn into a full one.

SteenSchmidt
Trusted Enthusiast

That is a good idea GregS, kudos to that Smiley Happy.

 

Regarding parallelization, I don't think you lose anything with my idea here. On the contrary you gain the ability to parallelize While-loops (when possible). On a general note you just do what you have always done inside the structure, coding each iteration as you normally would. You can use shift registers if necessary, obviously then throwing away the possibility for parallelization. But whenever your loop code is done you just hit "parallelize" (well, you drag in the P-terminal or whatever), and the compiler will tell you if you can parallelize what you have created or not. You don't have to try to figure out if you have created something For-like or While-like.

 

/Steen

CLA, CTA, CLED & LabVIEW Champion
JKSH
Active Participant

@vitoi wrote:

 

I think newcomers will find the existing For Loop and While Loop easier to understand than the "Universal" Loop.

 

I'm all for ease of understanding. That is my prime driver in most discussions.


One of my earliest mistakes in LabVIEW was an off-by-one error. The error snuck in because I THOUGHT I was using a while-loop to do counting, when I was actually using a do-while-loop.

 

For ease of understanding, LabVIEW should at least rename its "While Loop" 😉

Certified LabVIEW Developer
Ray.R
Knight of NI

Wow... You've really thought of this through...  You probably deserve kudos for the effort..

I have to think aboout all this and read all the other posts to see what people say before giving a kudo.. 

 

On the surface, it does seem like a nice idea..  🙂

fabions
Member

I kudoed for the great idea, but it needs some sharpening, maybe not get rid off the others, but add this one and also give more differences between the behavior.