Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Explaining what AF is (and OOP)...

Hi!

I have spent the last two days on the VIP days in Germany roving around through various sessions that were related to OOP and the Actor Framework. I have seen quite a large intrest in these topics, but also (really depending on the presenter) a large degree of confusion in participants eyes.

Concrete example: there was a session about OOP basics (presentation room was almost filled up to the brim) after which I perceived a lot of confusion under the attendees. The following LabVIEW User Meeting on the other hand was visited by only half as much people, although Eli held a nice presentation about AF.

Yesterday, there was a presentation solely about AF, same picture again.

At lunch, I had a little conversation with Eli about the "right" way to explain the AF to people who are still not that deep into OO. My perception is, that the presentations are more or less implementation centered (which ist cool for the experienced user) but I think (in the basic sessions), there should be more real world examples (maybe not even technical ones).

When I started with AF, I was also kinda stuck by the complexity and it greatly helped me to make up some analogies to real life.

What do you think about this?

Oli

Message 1 of 7
(7,863 Views)

Oli,

I am a LabVIEW user since 1992, LabVIEW 2.5.  I have been following the AF community messages which are forwarded to my email. I can't take time to read every one.  I still find the AF confusing due to its abstracts. 

In the beginning LabVIEW was pure dataflow left to right across your screen.  The big picture of the application was right there on the diagram.  LabVIEW was sold as self documenting.

Then came GOOP (object oriented by reference) and LVOOP (object oriented by value), and now AFOO ("roughly" object oriented message based simple tasks by a loosly coupled community of peer VI dynamically initiated by a launcher VI).

As I understand it the AFOO is the next step for LabVIEW to make it as scaleable and reusable as any other programming language.

Advantages:

1) scalable on demand at runtime

2) add / reuse / modify functions without rewriting the whole

3) use memory only as needed

4) take advantage of multithreading

5) abstract location of any AFOO function - might be useful on those little computers in your pocket with different OS.

6) probably lots more than I can think of

Disadvantages:

1) may not be the fastest for time sensitive tasks, if the task is across multiple AFOO actors

2) requires separate documentation like a text based program because the big picture is not on one simple diagram

3) requires reading the documentation and creating and maintaining an imaginary "big picture" from that in your mind like text based languages

3) so far for me a big learning curve, I am not purely a software guy, I design hardware and ATE also, I don't have a software theory degree

I do not know when AFOO is the best choice.  When is AFOO the only workable choice? 

I do know that for really simple applications pure non OO LabVIEW is the best.  When there is a need to swap hardware and for reuse, the LVOOP is best.  GOOP is wonderful, I have some great applications that use it, except the licensing forces only distributing executables (no problem) but every development computer must have the license even to properly load code created by GOOP.

Is my understanding correct?

0 Kudos
Message 2 of 7
(3,934 Views)

Oli_Wachno wrote:

I have seen quite a large intrest in these topics, but also (really depending on the presenter) a large degree of confusion in participants eyes...   My perception is, that the presentations are more or less implementation centered (which ist cool for the experienced user) but I think (in the basic sessions), there should be more real world examples (maybe not even technical ones).

Oli,

I agree with you 100%.  The AF is a good framework for building actor oriented applications.  But it comes with a lot of complexity that makes it hard for users to learn how to do actor oriented design.  For example, it's not easy to look through the Cooler example and pick out the concepts and decisions that are most critical to the design.  The core principles are lost among the details of dynamic launching and dynamic dispatching. 

The principles of actor oriented design can (and should, imo) be taught without using OOP at all.  Once the principles are understood, it's pretty straightforward to apply them to an application using the AF or any other OOP design.  If the principles are not understood, the developer is going to spend more time fighting against the AF than working with it. 

I've been working on a "Fundamentals of Actor-Oriented Programming" presentation off and on over the past six months or so.  My intent is to explain it without using the AF or OOP.  Unfortunately it's really slow work.  AOP is a different way to think about multi-threaded applications.  The paradigm shift is comparable to the switch from procedural programming to OO programming.  It's extremely difficult to cram all that information into something that is digestable.

RMThebert wrote:

2) requires separate documentation like a text based program because the big picture is not on one simple diagram

3) requires reading the documentation and creating and maintaining an imaginary "big picture" from that in your mind like text based languages

I disagree these are inherent disadvantages of AOP or the AF.  Assuming skilled designers, the need for documentation is primarily driven by the complexity of the application's requirements, not the implementation.  Any multi-threaded application with complex interactions is going to need some amount of documentation.

Regarding creating a mental model (the "imaginary big picture",) that's an automatic must do before I add or modify code in any application, not just AO programs.  The last thing I want to do is make a change without knowing how it will affect everything else in the app.  The "code and fix" programming process doesn't work well in professional programming environments--it's too unpredictable.  Whether the mental model is created by reading documentation or reading code depends on the application's complexity, the change's scope, and the developer's skill in selecting abstractions.

Message 3 of 7
(3,934 Views)

I've actually found the documentation easier to write for AF than for a standard LV program.  The UML Sequence diagram is one of the greatest things ever invented.  I've been able to explain a rather complex program to people completely uninvolved and have them understand what's going on in under 5 minutes, using those message/sequence diagrams.

If you've ever sat through a brutal code review for an hour (look, here's this thing nested 17 levels deep, it does something), you'll see the glory in the ability to convey behavior that quickly.

0 Kudos
Message 4 of 7
(3,934 Views)

I had never heard of Actor Oriented Design prior to my introduction to the Actor Framework.  I am very interested in the presentation you are putting together and am curious if you would be able to recommend any other resources for learning about Actor Oriented Design.

0 Kudos
Message 5 of 7
(3,934 Views)

RMThebert schrieb:

I do not know when AFOO is the best choice.  When is AFOO the only workable choice? 

To be honest: it depends... on many factors... which makes it hard to answer the question.

What I'm also telling from your message, you're understanding of the AF is also rather implementation based (correct me if I'm wrong). I think this is kind of second step before the first.

 

Daklu schrieb:

The principles of actor oriented design can (and should, imo) be taught without using OOP at all.  Once the principles are understood, it's pretty straightforward to apply them to an application using the AF or any other OOP design.  If the principles are not understood, the developer is going to spend more time fighting against the AF than working with it.

I do perfectly agree with Daklu; I really do believe that this must be the first step: to grasp what the framework is doing without all the details about OO, Priority Queues, ....

Let's talk about choosing a framwork like about choosing a vehicle: in order to choose one, you need to know about it's general capabilties (truck, car, bike,...). At this time you do not really care so much about facts like gearbox, color, engine .... Engineers often tend to dive into details too soon (so do I from time to time ;-).

Not promising, but I might find the time during the next days to work on a proposal: the motorbike is crated and on it's way to NZ and I'm having a off-site management training and two evenings I might get bored 😉

Oli

0 Kudos
Message 6 of 7
(3,934 Views)

Lossless_Larry wrote:

am curious if you would be able to recommend any other resources for learning about Actor Oriented Design.

Unfortunately I don't know any good resources for learning about Actor Oriented Design.  Part of the problem is the concept of an actor can be applied at many different levels and in many environments, each one with (perhaps) their own interpretation of "actor."  It makes it hard to talk generally about actors in a way that is useful to someone who is trying to learn about them.  For example, Wikipedia's entry on the actor model says,

"...the Actor model is a mathematical model of concurrent computation that treats "actors" as the universal primitives of concurrent digital computation: in response to a message that it receives, an actor can make local decisions, create more actors, send more messages, and determine how to respond to the next message received."

While that's true, it's not very helpful for Labview developers.  It doesn't explain how an actor is different from other concurrent execution implementations, such as a QSM or generic parallel loop.  In my opinion, the difference is all in how blocks of concurrent code interact with each other.  Actor Oriented Design puts more constraints on the interactions.  I freely admit the constraints seem like it should make the application harder to write and understand, but in my experience it makes it easier. 

(BTW, when starting out with actor oriented design I think it is more intuitive if you consider each loop a separate actor.  You'll quickly run into situations where it becomes ungainly to make each loop a full-blown actor, but I believe it's a good place to start.)

Actor Constraints:

1 - Actors control their own destiny. Actor A cannot force actor B to shut down. Instead, A might send B an "Exit" message, and if B is in a state where it can honor the request it will shut itself down. If B cannot shut down, it might ignore the message, respond with some sort of error message, or do something else entirely depending on what the developer wants. Contrast this with the common technique of using a front panel switch and local variables to stop multiple loops and you can see this technique violates actor oriented principles.

2 - Actors receive all information about their external software world via messages.  For example, you don't share a DVR between two actors as a way to exchange data.  One actor "owns" the data, and when the data changed it would send the updated data to the other actor via a message.  (There are a few exceptions to this rule I won't get into here.)

3 - Messages must be atomic and independent.  In other words, an actor can receive any message at any time.  For LV developers, this means you cannot write your actor in a way that depends on specific sequences of messages to be executed in order.  (Public sequence QSM implementations often violate this rule, which is why they have hidden race conditions so frequently.) 

Does this help at all?  My current thinking has these three constraints as the pillars of actor oriented design in Labview.  Whether or not they are helpful for people trying to learn AOD I can't say.  It's a complex topic that seems to resist too much simplification.

0 Kudos
Message 7 of 7
(3,934 Views)