Real For Loop

[tbob]

With text based languages, the For Loop has a programmable starting index, stopping index, and step size.  With Labview, the starting index is always zero and the step size is always 1.  It is not changeable.  I would like to see Labview have a real For Loop where there would be three terminals inside the For Loop that can be set by the user.  One terminal for initial value (starting index), one for final value (stopping index), and one for step size.  This would be of great value to all Labview programmers.  Of course the terminals can be much smaller than what is displayed in the picture.  One or two letter terminals, such as ST for start, SP for stop, and SZ for step size would do fine.  (or N for initial value, F for fnal value, and S for step size).  The real for loop should be capable of going in a negative direction, like starting at 10, ending at -10, with a step size of -2.

[AristosQueue (NI)]

> If you don't want it, you don't have to use it.

You'd still have to read it if someone else used it.

General comment: I try to discourage language features that affect a common use case and whose use is discouraged by a large segment of architects. If something has an arcane syntax but exists to solve one specific situation, that's fine. If something can be used in a common case, it should be something that most people are comfortable with, even encourage as "the right way". In fact, my real goal is that for very common tasks there is only one way -- not multiple ways, one of which is right.

How does that apply to this feature? Well, if we're going to be jockying around the For Loop -- the third most used node in all the LV palettes, after the case structure and while loop -- I want this to be something that is always available, that all of us see as an improvement to the For Loop, making it more usable. I don't want this feature coming in, being used by a few people, and ending up in a Style Guide as "not recommended".

I do think we can achieve that goal -- there's lots of conversation on this idea (and its twins in other threads) with lots of good suggestions. I just don't think the comment "well, don't use it if you don't like it" can apply to a feature that affects such a major common use case.

[TCPlomp]

If I see step of 2 I expect it to use every second element.

I was reading tbob's idea to implement such a structure:

So changing the step size would definetly change the indexed elements.

For the connectors I would recommend a cluster with the configuration.

[Intaris]

TC, I would have a major problem with that implementation.  I think it's very obscure code and I am aware of no precendence for that code behaviour.  But then again, I'm wrong on these things on a regular basis.

That would be a "Conditional Autoindex" which I think is a rare use-case.

@ tbob: Please don't assume a defensive stance against all us perceived boneheads.  I personally have nothing against progress but it needs to be in a controlled manner because once something gets into the loop (pun intended) it's there for good.  Waking up in a few years and thinking "Gosh, if we'd only done it this way...." won't make many happy.  There are clearly plenty of different opinions as to the best version for this so making sure we all agree on the best one is paramount.  I also started an idea to keep the loop as it is just so we can properly observe how many direct nay-sayers there are on this issue.  I think this is an important aspect to this before we change an integral part of LabVIEW.  If we don't think enough about this before implementation, it'll come back and bit us in the rear!

[tbob]

I fully agree with what you said TC.  After looking at my original post, and all the ideas, pro and con, that came afterwards, I realize that my original post was not well thought out. 

I will try again because I think it is a tool that could be very valuable.  My new proposition will include examples of how it could be of great benefit.  It will also include statements about how it will not affect the way we use the loop now, including an example. 

 I look at this like the idea behind adding the conditional terminal to the for loop.  Some were against it saying we could do the same with a While loop.  They were correct.  But still the addition of the condition terninal was really a good idea, good enough for NI to implement it.  What was good about it was that you didn't have to use it and it didn't show up unless you specifically right clicked for it.  My new idea will show that the for loop will look and feel the same, making it backward compatible, and making it transparent to those who want to keep it like it is.  It will take a right click to activate the new features. 

I'll publish it in a few days after planning it out better.  Please look for it and keep an open mind.  The example code I plan to include will show its merit.

[Intaris]

@tbob.  Sounds very reasonable.

Just my 2c on the actual functionality (rather than on whether it should be done or not).

I don't like the idea of start, step, stop.  My brain, when dealing with FOR Loops dealy much better with start, step, N.  I always end up doing arithmetic (badly) in my head trying to work out exactly how many steps the first option would execute.  I tend to find the number of steps more important than the end value as the start and step values normally fit the data being processed and not the other way around.  For me defining N in this way is unnatural.

[ASInc]

AQ, why then, if the For Loop is the 3rd most used node, is it NOT on the Express>Exec Control palette?  Since by default, LabVIEW makes the Express tree the one that opens on a right click BD menu on a clean LV install, it seems to me it should be there.  There's even a blank spot on that palette for it.  This is one that has never made sense to me, AND I can't seem to find a way to customize my menu to put it there.

[Intaris]

There's an express palette??

[tbob]

There is an express palette on my controls palette (front panel) and on my functions palette (block diagram).  I never use them.

Please guys, give me a chance to come up with a much better worded and illustrated idea for the for loop.  It will appear within the next few days.  I think everyone will be in agreement with the new idea.  Until then, lets leave this discussion alone.  We are beating a dead horse.

[AristosQueue (NI)]

While tbob is creating the new version, I'll answer the tangent question:

> AQ, why then, if the For Loop is the 3rd most used node, is it NOT on the Express>Exec Control palette? 

This is how it has been explained to me: LabVIEW has two major categories of users, and they are completely disjoint in their interests and desires. One group, which I'll calll Express users, use LV exclusively as a measurement tool, not as a programming environment. Express users -- and they are a substantial percentage of our total user base -- use the While Loop and some Express nodes. They rarely use the case structure and have no general need for the For Loop. The Express users form a big enough percentage of our user base that we need to serve them. The other group of users, who I'll call the programmer users, appears to rapidly figure out how to switch their palettes to the other view. If we start with the programmer view, the Express users never flip to the Express view -- they just get frustrated at too many options and quit using LV.

[tbob]

AQ:  You guys are making Labview way too easy to use.  Its really causing us real programmers some problems.  Management thinks any Labview coding is trivial and won't allow us time to code properly.  We get bombarded on this forum by novices who have no business trying to code anything.  I know NI is in the business for making money and that express VIs are here to stay.  But I just wanted you to know the dark side of Express VIs.

I like your last sentence.  If they get frustrated with Labview because it takes a little knowledge to use (of which they have none), then let them quit.  Management will then turn to professionals to do the job.  More jobs and more reasonable schedules for us professionals.