Make locals good again

[jspinozzi]

I fear this may be an old-school post, but unless I've missed a recent update, it's my understanding that fundamental LabVIEW teaching is that Locals duplicate memory and should be sparingly used.  I've always known it, and I've ALWAYS disobeyed it.  I love locals and I think they make code cleaner and encourage their use. 

So my idea is, if Locals waste memory, please make them NOT waste memory.  A local should be the functional equivalent of updating a Value Property Node in LabVIEW, and of stating VarName = 1234 in any other programming language in which I can set the value of a variable as often as i want anywhere I want, and it doesn't waste memory.  So if we can make Locals good again, all the more harmony.

Here's hoping this is a good/novel idea, yet if it's already fixed then Kudos to NI.  I'd hate to think they have structures in LabVIEW with a note that says "PS... don't use this" in the training material. 

If I'm wrong about their fundamental behavior now or earlier, let me know. 

[altenbach]

Wasting memory is just a small side issue and typically not a problem.

Local variables break dataflow and introduce potential race conditions that can only be cured by excessive use of sequence structures. Two wrongs don't make a right!. Data belongs on the diagram. Why would you abuse user interface elements (controls, indicators) for data storage? They are not "variables" in the same sense you seem to be using them. A diagram with many local variables is not cleaner in any meaning of the word. They take up way more space than a wire and since they are read/written all over the place and in potentially random order, debugging is orders of magnitude more difficult. They also break the distinction between controls and indicators.

Start reading here.

I would recommend to start a new thread in the LabVIEW or breakpoint forum. Show us your diagrams and explain in plain english the virtues as you see them. Let's get a meaningful and applied discussion going.

Local variable do have their use, especially when dealing with UI features.

Reading between the lines, you also seem to have the misconception that updating a value property is somehow more efficient that a local variable. This is far from the truth. Since property nodes execute synchronously, they can be several orders of magnitude less efficient than local variables. (See e.g.. DFGray's post here)

No kudos here! 😄

(And why do you say "... again" in the title? They were never good in the past. 🐵

[drjdpowell]

The analogue in LabVIEW of "VarName = 1234 in any other programming language" is really the wires.  Data flowing through multiple nodes is setting the variable multiple times.  

That is, if one is comparing to a single-threaded program in another language; if one is instead accessing the variable from multiple threads in parallel, then that is similar to using local variables in LabVIEW.  BUT, parallel access to variables like this is problematic and dangerous in any language, and should be discouraged (or at least limited to simple things like writing one place and reading in one other place).

[jcarmody]

What's the problem?

[altenbach]

> What's the problem?

I thougth this was about local variables, not globals. Did I miss a memo?

[jcarmody]

Sorry.  I'll pay more attention in the future.

[Ray.R]

The better idea would be to reduce access to Locals.. 

I can't add more to what Altenbach has already explained.  Plus I agree with drjdpowell

Loving Locals is a bad thing.  Certainly won't get you employment in my company.

Maybe it's time to post an idea about negative Kudos.

and..

LOL!!  @ jcarmody !

[crossrulz]

Ray, sorry but the "Boo" has already been suggested:http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Create-the-OPPOSITE-of-KUDOS-ie-BOO/idi-p/1280260

[Ray.R]

LOL!  I missed that one.  Interesting discussion in that thread.  Well suited, too. 

[MaryH]

This idea has been declined by LabVIEW R&D.