While reading on the subject of LVOOP, I discovered that LabVIEW does not have the concept of variables. Below is a quote from that article..
"In summary, LabVIEW, as a dataflow language, does not normally have variables. Wires are not variables. Front panel controls are not variables. Even local or global variables are not allocated with a specific lifetime, the way variables are in other languages. Variables are part of a model that conflicts with dataflow. Without variables and a way of defining the lifetime of those variables, construction and destruction are meaningless concepts, and therefore we left them out of the initial language design."
So why do we tell people that the wires are the variable when there is no such concept in LabVIEW?
I actully say that wires are similar to variables. I specifically do not say they are variables specifically because they do not have a storage scope or concept of existence. The only time the value is "read" is when the wire terminates. You cannot read it at any time. like a physical memory lcation (which a variable is) like other languages. Probably the most similar equivilant would be to say a wire is like a local variable in a traditional language. This value is only stored while in that module and its scope is confined to that module. However, defining scope on a wire is not as easy since the compiler can dispose of it once it has determined nothing else will access it. Scope is not as clearly defined in a dataflow language.
However since people coming from traditional languages think in terms of variables it helps to give them some concept of a variable in LabVIEW when teaching them to write code. By at least sying the wire is like a variable you can help to avoid people littering their code with tons of local variables and front panel objects.
I fully understand what you described and agree with it. The reason I posted this thread is because often I would read replies stating that it was, myself included... For the reason that you mentionned. When I read the paragraph in the article, my first reaction was "what??!!", and then as I though about it, it made sense. Although you can proble it, the wire is more like a reference to a memory location...
I can understand why we would say it is (or is like) a variable, because you can change the value along the wire with functions, terminals (control), or property nodes, etc. With the concept that the value may vary, the closest text-base object would be the variable.
I figured I would open the can of worms with this thread and get feedback as to what we should post when people have difficulty grasping the dataflow concept or a graphical language. If you do not mind, since I like what you posted, I would use a modified version of your explanation.
No problem. Feel free to use it. Just remember to pass the kuods along.
some extra ones to get you started
I'll take a sling at it.
The wire is data
the wire has a type property (like a variable)
the wire has a buffer associated with it (like a variable)
the value in the buffer can be accessed by a DVR (like an object)
Interesting choice of terminology Data Value Referance not Wire or variable referance but a reference to the value
it has a copy method (like an object)
we pass data from function to function and node to node
we copy data from buffer to buffer where a function can modify the buffer contents
Essentially without the node the wire is not a variable. But a wire and a node together define a variable that the function attached to the node needs to operate. (I bet that's why broken wires allways break the vi. Data without use and variables without value)
A Wire is a quantum string phenomenom! It's a string in space (wire on diagram) with undefined value until you read it!
But does the mere act of reading the value of the wire potentially change it's value?
Actually it does, since i found a bug in 2010 beta whereas a calculation would fail unless i had it wired to an indicator ...