LabVIEW, Dataflow, OO, By Value, By Ref (take 2)

[Jacemdom]

Salut.

The discussion in this thread is really out of the topic. The discussion here seems to be if OOP is needed in LabVIEW or not. I especially started a new topic to discuss the ways to implement synchronization of shared resources between multiple threads. I'd appreciate if you dear virtual architects could stick to the topic or at least close to it. If you would like to discuss about OOP in general, please start a new topic for this issue. Especially if you would like to blame one another, start a new topic within the LAVA lounge about why X.X.X. is a bad programmer or what ever. It is very hard for people to find relevant information from this forum if the topic doesn't describe the discussion at all.

If i slip again and don't see it by myself, i always appreciate being awakened...but i believe i will remember the amount of work that i needed to do in order to try an clear things up so that the information may be more inline with the original topic that i most probably will triple verify to stay inline with the major topic of the topic or create a new post. As for the damage done in the threads refered in this discussion, i do not have the power to clean them out. Only an admin could do that...

This post could be considered to be quite long (so long that the quote formating stopped working and forced me to post it in 2 steps using the add reply ) as i'm going to dig up all the spilled bits and pieces of discussion that ended up hijacking the work of others in vaguely related topics, so that this discussion as well as the others can continue on their way...i will also intentionnaly leave out some comments that i (or others) made that don't add any significant value in the discussion.

Example :

It never came to your mind that all you "Power users" where not respecting the very nature of the tool you are using? DATAFLOW

I just noticed that by wanting to use it as an example of things to leave out, i actually inserted it back... even if now could remove it...should i...could i...do i really really reallllllllly want it...i will let you discover...you already did

So here goes...

PART 1 : History, spilled bits and added comments.

From The need for lock in get-modify-set pass Options

QUOTE(Aristos Queue @ Oct 5 2006, 05:14 PM)

The by-value syntax is just as meaningful for objects. In fact, in many cases, it is more meaningful. But you have to get to the point where you're not just looking at system resources as objects but data itself as an object. Making single specific instances of that data that reflects specific system resources is a separate issue, but is not the fundamental aspect of dataflow encapsulation.

jacemdom replied : Could data be just seen as data?

QUOTE(Mads @ Oct 6 2006, 05:49 AM)

Let's say that you want to teach someone what object orientation is and how he should design an object oriented program...how do you do it? One of the core concepts then is that he should try to not think of functions, but real life objects. If he wants to create a car simulator he should think of what kind of objects a car is made of and create the equivalent in code, he would need to make an engine object with its attributes and methods, consisting of smaller objects with their attributes and methods etc. etc....

jacemdom replied : Is a motor really and object or a function to transform air and gaz inputs into mecanical force output?

Mads replied : It is an object if you choose to view it with an object oriented mind, that's the whole point.

jacemdom replied : i don't see objects when i model (software or any other modeling)...i see data and functions that act upon it...i don't unite them as one to create objects...i see them seperated...

LabVIEW Object-Oriented Programming: The Decisions Behind the Design

For those who choose object designs,

we want wire and node

to morph naturally

into class and method.

I created a similar relation about 5 years ago, to be able to differenciate the LV concepts from the OO ones, that went :

In LabVIEW there are containers (contain data, wires, globals, queues etc...) that are similar to the properties of objects and there are functions (transforms the data, VIs, VITs, LV Blocks) that are similar to the methods of the objects. A definition of a container is a domain (Type def cluster) that is similar to an OO class.

So i created a way of modeling the architecture of an app entirely using a naming convention representing this. For more details see

http://forums.lavag.org/index.php?s=&s...ost&p=17238

robijn replied : Noone should force you to use OO. To use OO should never be a target on itself. All programs I'v written that use OO aspects don't do that everywhere, only for the parts that it's useful. But I don't think the usefulness of OO is something that should be discussed here. It's already in and it will never leave LabVIEW.

And obviously you can build OO systems without native language support. "C with classes" was the first implementation in C, it was done only in #define's etcetera.

jacemdom adds : the othe day wondering on that discussion in front off my tv i asked myself...is the tv an object? I answered myself, no, it is function that transforms basically 2 data inputs (electricity and tv signal) into two outputs (screen and speaker). That is own i model my environment. I am also a function with multiple inputs and outputs, not an object with attributes and methods...can't say that i never saw myself as an object and that i'm trough with those ideas flowing in my dataflow mind...

QUOTE(Jacemdom @ Oct 9 2006, 12:55 AM)

I don't believe that LV lacks native by ref modeling tools. If NI wants to add them in the future, so be it, as long as they never forget the original simplicity of the dataflow implemented by the fathers of LV.

robijn replied : I agree with you that's essential. I believe there is a lot of power in dataflow. The route of the data on the diagram tells so much. But dataflow only works locally, in a VI and towards its subVIs. For the app as a whole dataflow is not appearent. We use functional globals all the time (I hope you do as well!) to store more complicated things that need to be accessed from multiple places. A functional global does not follow the dataflow paradigm, as it stores data in shift registers. So at that point the dataflow ends (or starts). You can use dataflow up to the functional global, and even inside the functional global, but once you place that functional global in multiple VIs the dataflow is disturbed. The same modified data does not flow in and out, a lot of data may be stored inside the VI.

Dataflow is a great concept, but there are limits to it. The trick is to go past the limits in the best way. A functional globals is a such way, the event structure - a fascinating solution by NI - is such a way and native referencing OO would be another.

QUOTE(Jacemdom @ Oct 9 2006, 12:55 AM)

Can "by ref" OO offer, you have bug, follow the wire?

robijn replied : You mean you are affraid debugging is going to be more difficult ? Then NI should add features to make that possible. It is quite important to keep it "Rapid development".

jacemdom replied : That is my question...How can you make that possible? How can you make a "follow the datawire debugging" scheme in a by ref design? I don't see how one can follow the data in a by ref design...

robijn replied : You could attach a probe to the wire and see what the object's attribute's values are... You could open a diagram and set a breakpoint. Maybe you could have a front panel and block diagram per instance of an object...

In the diagram things don't look different at all. It's only the behaviour on life-start and life-end where things are different. The current systems creates a new object when you branch a wire, and removes an object from memory after the data in the wire is not used anymore (this is the simple version of the story ). A referencing system creates an object on request (allows to have a constructor) and removes it on request (allows for a destructor; may allow for automatic destruction when an object is not used anymore but this is tricky business). The fact that the programmer needs to request a new object prevents having "parallel universes" by accident. The "request to create" could in practise be the constructor placed on the block diagram, just like a method is placed now.

jacemdom replied : Using analogy, would the by ref implementation in LabVIEW be like designing a sewer system that enables the water and the treatment plant to go trough the pipes all together?

Mads reply from Implementing synhronized access to shared objects, How should NI implement synchronized access to by-ref objects Options : I assume the sewer system analogy is an analogy close to how you view wires in LabVIEW...and you do not understand how we can talk about objects instead of data going through that sewer. The sewer analogy however is way too limited to describe the wire in LabVIEW - LabVIEW already have tonnes of by reference wires which do not fit to that analogy (even though you try your hardest to make it fit). You should in other words be used to think of the wire as something that can send a reference, not always the items (sewage in this case) themselves...

jacemdom adds : From The LabVIEW Platform, Part II

[robijn]

Hey that's a very nice... uhm well summary is not the right word. The discussion is quite complex as this shows. Thanks for the effort.

I think referencing objects do not give a real conflict with dataflow. You only need to realise that if you use them at multiple places you may get a problem. But I think LV should solve that with native locking, in whatever way. There's a separate thread for that. If this locking is done, there is hardly any difference left between a containing wire and a referencing wire. Then the locking mechanism instead of the dataflow mechanism will arrange the serialisation. A starter won't notice.

Joris

[bsvingen]

Dataflow is comparable in nature to a city water distribution system. Block diagrams consist of functions (A water distribution system is composed of treatment plants, pumps...), which are represented by icons (that have a certain appearance), wires that connect these icons (Pipes that connect the different elements), and structures that control execution logic (And relays that control the opening of valves). Data flows from one function to the next (Water flows from the treatment plant to the pumps), and the functions and VIs do not execute until all terminals or wire connections have data available for processing (And the pumps will not work if there is no electricity and water).

I work with similar systems in power plants, and have made an application in labview that analyze all the flows, turbines, pumps etc. Your analogy is not correct. Dataflow is completely different from water flow, or any other physical flow for that matter. There are several reasons for this. First, the basic properties (temp, pressure, density, velocity) changes along the "wire" (pipe). This means that the pipe - wire analogy is not there. A pipe is a function, an icon, just like the other functions. Secondly, physical properties cannot copy themselves, since this will voilate the basic law of mass conservation.

OK, maybe i sound like arguing just for the sake of arguing, but the mass conservation principle is in fact a bit important. It is the reason why dataflow cannot be used for abstraction of physical processes. This abstraction requires a by ref construct where you can control this basic physical property. I pipe is an object, with proerties as length, diameter and so on. Then it has state variables, such as temp, pressure etc distributet along the length, it has functions that relates all these variables in both space and time, and most importantly it has communication that talks to the neighboring elements. In Labview it is this (very abstract and mathematical) communication that is the wire, or more precisely the wire is only a reference to the communication process and the start and the end tells the process who shall communicate. The rest is an object, one single instance of several.

[Jacemdom]

References co-exist with dataflow because the refnums themselves are dataflow

From my point of vue, references in LV ressemble more like "Serialization" than dataflow. Could you elaborate a bit on the subject?

OK, maybe i sound like arguing just for the sake of arguing

I never feel like i am or that soemone else is arguing just for the sake. This is an object world concept. What i do believe, is that some of my "outputted" ideas(data), especially the water analogy, flowed from the interior of my head and "inputted" into yours to be processed (functions) and "outputted" from your head and "inputted" into mine, was processed (functions) and created.

That brings me to conclude (like i don't remember who talked about this in thos discussion) that there can be flows without wires, like a wireless phone...the flows are just harder to follow and the data is thrown in all directions and can possibly and will cause some interferences

So water analogy take 3 :

In order to easily understand the basic principle of LabVIEW, one could take the example of bringing water (actual wanted information, called data in LabVIEW) into your house so you could drink it. You first have to find a suitable terrain for your project (this is called a diagram in LabVIEW). You then start out from the lake (contains the information or data you want to acquire or pump) where you would insert a pump (acquisition function, called a VI in LabVIEW) and then use pipes(called wires in LabVIEW) to bring it to the filtration station (another function) and then through more pipes (wires) to finally reach the final function that is your Tap(that also serve as the user interface for human interaction, called a front panel in LabVIEW)

By the way, i don't have any real hands-on practical experience with the standard OO by ref implementation in any languages. This is in part due to tha fact that when i come in contact with one of those i react badly and this is probably due to my nature of not liking complexity. The way i see it is you live it, you learn it, you code it, you forget about it! And i must say that i appreciate greatly what LabVIEW as avoided me for all those years. But what i have though is years and years and years and years of modeling around it, over it, under it, and the further away as possible from it, to have come to the conclusions as a general life concept, that an object view of the world is not what will enable humanity to solve the challenges ahead because of its deconnected nature that make people really believe thinghs like ther is a physical part to my body and there is a psychological part to it and they are not related. This is also the model that made humanity beleive that there is the trees, and there is the air and there is the exaust of my car and there is relations between that and the rising incidence of asthma. This is what basically and fundamentaly triggers me away from objects. In the dataflow world you don't have disconnections, you have to follow the flows of things. The exhaust outputs certain chemical that my body will input even tough it can eventually kill it. That is why i have said in an earlier post :

"Some people see objects and believe that they exists and generate data, some others believe that the data exists and the objects are a particular state of the data...if we live in an object world, who decides where are the boundaries?"

All this discussion about LVOOP, GOOP and everything made me realise how much i love the idea of dataflow and how it was implemented until now in LabVIEW and to see if LVOOP can enhance my dataflow experience by simplifying it even further :question:

[LAVA 1.0 Content]

LAVA sent me a "New Topic Notification" on this topic. My email program considered the notification was junk and filed it to my junk folder... Never happened before with LAVA forum notifications. I've to disagree with my email program, which is btw Mozilla Thunderbird. Seriously thanks for the effort Jace

[Guillaume Lessard]

So water analogy take 3 :

In order to easily understand the basic principle of LabVIEW, one could take the example of bringing water (actual wanted information, called data in LabVIEW) into your house so you could drink it. You first have to find a suitable terrain for your project (this is called a diagram in LabVIEW). You then start out from the lake (contains the information or data you want to acquire or pump) where you would insert a pump (acquisition function, called a VI in LabVIEW) and then use pipes(called wires in LabVIEW) to bring it to the filtration station (another function) and then through more pipes (wires) to finally reach the final function that is your Tap(that also serve as the user interface for human interaction, called a front panel in LabVIEW)

On my first contact with LabVIEW back in 1997, I tried to see it a bit like you argue; being an *analog* electrical engineer by training, I thought about circuits.

However, having been well trained in circuit design and analysis by some wizards of analog electronics, I just could *not* *understand* LabVIEW.

That's because LabVIEW is *nothing* like a circuit. Not even a digital circuit; that is not even a digital circuit from which the clock is abstracted. And a water distribution system is even more complex than a standard electrical circuit, because it has to contend with scaling physics across and along a single pipe that an electrical circuit never even has to deal with...

Of course you can model such a system in LV if you want, but it's not going to look simple, and you're in fact going to be operating on queues and buffers, not simple dataflow. For an idea of the consequences of correctly modeling an analog circuit on a computer, I suggest something like "Discrete-Time Signal Processing" by Oppenheim and Schaffer.

[Jacemdom]

First, the basic properties (temp, pressure, density, velocity) changes along the "wire" (pipe). This means that the pipe - wire analogy is not there. A pipe is a function, an icon, just like the other functions. Secondly, physical properties cannot copy themselves, since this will voilate the basic law of mass conservation.

For the first point :

Does this mean that you believe that the wire in LabVIEW is really a wire? What do you think the wire is when you decompose it and dig further in the LabVIEW core? I would tend to say that it is an object with properties and methods... And what are those Objects? lines of code...and what are those lines of code? series of bits...and what are those series of bits? gates that allow or disallow the flow of electicity or dataflow!

The analogy is just there to allow some non CS people to understand the dataflow basic idea. Data flows trough a series of functions and thus is transformed...

Do you really beleive i'm trying to establish pipe = wire?

For the second point :

Could you then explain what is mitosis?

From Wikipedia

Mitosis is the process by which a cell separates its duplicated genome into two identical halves.

Thought of the day :

Complexity can be caused by poor abstraction...or out of context reasonning...or biting a bigger peice than you are able to chew...

Eating a sandwich bite by bite is simple, putting the entire sandwich in your mouth creates a period of complexity that can ultimately lead to death...

Anyone remembers those first experiments of trying to put as much as possible in your mouth and try to eat it...

[bsvingen]

I don't know what the jargon "non-CS people" are but i look at it like this:

Dataflow is by itself very easy to understand. What is not easy to understand is why dataflow should make programming any easier or more intuitive. Also i don't think making analogies with dataflow and real world processes will make dataflow easy(er) to understand, because those analogies will be much too inaccurate to be good analogies.