Is LabVIEW Object Oriented or Actor Oriented?

[drjdpowell]

On the question of whether LV is object oriented or actor oriented: Neither, inherently. Both of those are design styles, and they are orthogonal to each other. One speaks to a way of data packaging (object) and the other speaks to a way of controlling execution flow (actor). 

Are they “orthogonal”?  Actors encapsulate their internal data, and messages to the actor can be thought of as methods of an object.  

[Aristos Queue]

They are orthogonal insofar as the implementations of either do not require stepping on the domain of the other, though they certainly may. A lot of this is philosophy of categorization. There's no right or wrong answer, really. To me, it helps to see them separately because it emphasizes the domain that each has when designing software.

[manigreatus]

"On the question of whether LV is object oriented or actor oriented: Neither, inherently. Both of those are design styles, and they are orthogonal to each other. One speaks to a way of data packaging (object) and the other speaks to a way of controlling execution flow (actor). It is possible to design a system that is pure procedural, purely object oriented, purely actor oriented, or both. Such systems can be built in just about any programming language. Having said that, various languages provide syntax support to make it easier to implement these designs. LabVIEW supports object-oriented programming through the .lvclass files and related features. LabVIEW supports actor-oriented programming through the queues and VI Server systems. The Actor Framework provides syntax to unify the two, though there are plenty of other ways to achieve that effect."

Thanks for your explanation. But I see a VI/module in LabVIEW as an actor which implies that LabVIEW is inherently actor-oriented (AO). We can implement an actor even without using VI server and queues by just having a while loop and a local. For me one of the most attractive things in LabVIEW is its simplicity, you can design complex systems even without knowing the programming paradigms (say AO) and that's the beauty. I think in Actor Framework things have been made pretty complex by mixing OO and AO. At this point I have a question that is Actor Framework reflecting what is described here:

 

http://ptolemy.eecs.berkeley.edu/publications/papers/07/classesandInheritance/Classes_Final_LeeLiuNeuendor.pdf

 

For advanced users its really a nice idea to introduce two different programming paradigms and then show them how these can be combined but for average users it is complex. I think apparently we needed  "inheritance" and  "encapsulation" from OO in AO why not introduce something say "Actor VI" and associate encapsulation, inheritance etc. with that without having a .lvclass. In this way we can abstract the OO stuff from the design since in Actor Framework one needs to keep track of classes and also the actors which makes it complex. Please give your suggestions and correct me if I am wrong since my goal is just to keep LabVIEW simple but powerful

[Aristos Queue]

manigreatus: Yours is certainly a valid way to look at it. What is key is that there is some communications mechanism between independent pieces of code. If that's a local variable for you, great. For me, that's always a queue/notifier/event as I have simply had too many problems with local variables to ever use them as a synchronization tool (even just a simple stop button runs into issues with mechanical action and requires extra code to reset the local, code that is too often forgotten).

I think in Actor Framework things have been made pretty complex by mixing OO and AO.

The AF is meant to solve hard problems, not to invalidate the basics of LabVIEW. When you start having a hierarchy of actors, need for lots of code reuse, or many actors that are similar to each other but not quite identical, then the AF comes into play.

At this point I have a question that is Actor Framework reflecting what is described here:

http://ptolemy.eecs.berkeley.edu/publications/papers/07/classesandInheritance/Classes_Final_LeeLiuNeuendor.pdf

Yes, pretty much.

why not introduce something say "Actor VI"

Because an actor is not and cannot be defined by a single VI. A VI is one function. A .lvclass *is* simple -- it is a set of functions, and the Actor class defines an entire Actor. You just don't have the richness to define functionality in a single VI. Besides, most actors need private support functions.

[manigreatus]

Because an actor is not and cannot be defined by a single VI. A VI is one function. A .lvclass *is* simple -- it is a set of functions, and the Actor class defines an entire Actor. You just don't have the richness to define functionality in a single VI. Besides, most actors need private support functions.

I didn't mean a single VI with "Actor VI", of course a single VI can't do the job that efficiently. Actually I meant to say that some type of file .lvclass (say .lvactor) that will hold all the stuff (messages, functions, etc.) related to that actor. Currently you define actor by one .lvclass and messages to it are some other .lvclass; why don't we combine these together? I mean if you are using actors then these should be actors not objects. Anyway  it would be almost the same thing what we currently have, I thought if we abstract OO part from actors then it would be easier to play with them.

[bsvingen]

Then, is it correct to say that dataflow is inherently actor oriented?

[manigreatus]

Then, is it correct to say that dataflow is inherently actor oriented?

 

Not necessarily but it can be utilized to achieve the actor-oriented design.

[Aristos Queue]

I didn't mean a single VI with "Actor VI", of course a single VI can't do the job that efficiently. Actually I meant to say that some type of file .lvclass (say .lvactor) that will hold all the stuff (messages, functions, etc.) related to that actor. Currently you define actor by one .lvclass and messages to it are some other .lvclass; why don't we combine these together? I mean if you are using actors then these should be actors not objects. Anyway  it would be almost the same thing what we currently have, I thought if we abstract OO part from actors then it would be easier to play with them.

Your idea is clearer now. I thought you were trying to pull inheritance out of the picture entirely. With the clarification, I am more agreeable with your idea. I certainly wouldn't rule out a better system of implementing actors+inheritance... I've got several sketches for such variations in my notebooks. :-) Having said that... most of my recent sketches have moved me in a direction that would not create a .lvactor separate from .lvclass but instead would move *all* classes toward being more actor-like. I'd like to be able to handle the by value data model and the by reference process model in a single unified code base so that there aren't two different programming styles depending upon which system you need/like more.

[Val Brown]

I'd like to be able to handle the by value data model and the by reference process model in a single unified code base so that there aren't two different programming styles depending upon which system you need/like more.

 

I'd like to hear more about that, if not here, then in another thread.