Change the name of local and global variables

[SteveChandler]

Many of you know that the things called variables in LabVIEW are not variables at all. This regularly causes some confusion. Ben elegantly explains this here where he suggests that a local variable in LabVIEW is more like an I/O device.

I propose that they be called something like I/O device, I/O register or I/O buffer. Maybe "Control Buffer". The idea is not to call variables something in the list but to simply come up with a better name.

I understand that there is a lot already written about LabVIEW that refers to those things as variables and that much documentation would have to change. But I think that LabVIEW documentation should at least start to call "variables" something different.

At a minimum this should be clarified in the documentation on variables.

[crossrulz]

I must admit, I'm torn with this one.  Yes, it is the most common problem when text programmers come over and start abusing locals relating them to x.  But after 26 years of LabVIEW, it would be really hard to change something so entrenched.

[SteveChandler]

But to change anything requires a start. Just an explanation in the help would be a nice start. I'm sure you are not against that.

[crossrulz]

>But to change anything requires a start. Just an explanation in the help would be a nice start. I'm sure you are not against that

There should always be a strive for better documentation.

I just looked at the LabVIEW help for a Local Variable.  All it talks about is reading/writing front panel objects.  I would definately agree that something should be put in there about not using it as a "variable".  On those grounds, I'm giving this a Kudo.  The rest of the idea, I'm still torn.

[AristosQueue (NI)]

How exactly is it not a variable? If the panel is not open, the local variable doesn't do anything to update the panel. It just is a place where you can write and later read a value. It's a variable. So are global variables. So are network shared variables. And they're all problematic. But anything that is a variable would be in a dataflow environment. I think the name is accurate.

[SteveChandler]

They are kind of like a variable in that they can hold a value that can vary. But they are not the same as a variable in a text based language. The way that they are sometimes used is like creating a hidden control in a C# Windows application just so you have a place to store a value. By calling LabVIEW local variables "variables", it understandably implies to someone new to LabVIEW (but not new to programming) that this is what you use to store local data.

Maybe calling them something else is kind of drastic. It would be like naming your kid Mark after you had been calling him Jeff for the first ten years. Confusing for everyone. But I bet people would get used to it in time. Just please don't call local variables a "heap-allocated pointer to data allocated within the function" 

At a minimum the documentation for all of the types of variables should include an explanation of what they should and should not be used for.

[AristosQueue (NI)]

In C#, I could declare a variable and then separately bind it to a display. But the variable is the variable regardless of whether I do that binding, just as the variable exists regardless of whether the panel is showing or not.

To go further: controls are how you graphically declare types in LabVIEW. The memory location exists, and having a panel display helps with the debugging of this memory location. To me, that extra debugging changes nothing about whether or not it is a variable vis-a-vis the program I write to use that variable. Within my function (for locals) or application (for globals) it is exactly equivalent to a variable.

[SteveChandler]

I accept and understand that local variables are variables in a strict sense. But getting to the spirit of this idea they are not variables in the classic sense and should not be used as such. Wires are the variables and they are not really wires . I got that from people much smarter than me in the discussion that I linked to above and various others.

Maybe this is a stupid idea. Changing the name would not prevent them from being used for things they are not intended to be used for.

[AristosQueue (NI)]

Hm... I see where you're headed with this now... it isn't so much that they *aren't* variables, it's that they aren't the *right* variables.

Yes, I could get behind an idea to rename them "not-safe-for-parallel, inefficient data storage pits of despair". Or something like that.

[SteveChandler]

I think that name is right to the point - very clear and concise. I like it!

[crossrulz]

"inefficient data storage pits of despair" -