Facts and opinions on the Actor Framework as a LabVIEW add-on

[BertMcMahan]

The biggest perks of AF are, IMHO, the messaging part and the asynchronous launching part, not the "state machine*" part. Calling it a "queue driven state machine" is both incorrect and overly simple. Yes they're "state machines*", but it lets you trivially launch multiples and use them ephemerally without needing to manually create VI's to launch and handle an arbitrary number of clones. It also gives you a very robust messaging paradigm to use between each actor.

*It's also better described as a queue-driven message handler. It's definitely not a state machine by itself, though I think I understand why you called it that. Lots of people around here call anything a state machine that uses a case structure called by a queue, which can be (and frequently is) used with state machines.

I haven't used the others so I can't say whether this differs from the other ones or not. You replace a bunch of modules with AF, and now they can talk to each other and inherit from each other. I do agree that the learning curve is steep and that you REALLY need to be comfortable with OOP before you can be comfortable with AF.

I personally use AF and quite like it, but that's just because it's the one I'm comfortable with. I'm sure the other solutions you're posting would work fine as well.

[drjdpowell]

---

@crossrulz wrote:

---

@skinnedknuckles wrote:

I am researching LabVIEW framework add-ons to help our group choose one for all future projects.

---

I would advise against this.  Don't be dogmatic in a framework.  I've seen too many applications become WAY too complicated trying to fit into a framework when a simple single loop with an Event Structure would do the job (I may be slightly exaggerating here, but the point is still valid).  Learn many frameworks/architectures and figure out which one fits best with the project requirements.

---

An important characteristic of a good framework is that it is widely applicable to a range of project complexities.  Simple things should still be simple.  The basic unit in Messenger Library (the "DEV template") is basically an Event Structure in a single loop (and can be used as such) only with inbuilt error handling and multiple ways to add capability.  I've delivered multiple projects using only one such Event-Handling Loop, that would have to have been significantly more complicated if I had started with a simple Event Structure in a loop.  Real world applications always have some extra requirements that exceed the capability of a simple Event Structure in a Loop.  I would say a major advantage of Messenger Library is that easier and quicker to develop with it at all project complexities, and one never has to "fit into the framework". 

[drjdpowell]

---

@skinnedknuckles wrote:

Below I've listed facts and opinions about the NI Actor Framework as "feature: value" pairs that I've found online from multiple resources.  I'd be happy to consider any

---

BTW, you should add "Ease of Network Communication" to your list, if there is any chance you will desire communication between EXEs (on the same or different computer).  With Messenger Library network communication is quite easy** and I often use separate EXEs for special tasks (examples: making 32-bit-only hardware available to a 64-bit main application, having a "Watchdog" exe monitoring a long-running app and restarting it if needed, having an external "Tester" exe that runs tests on the main application).  

**caveat: network communication can never be completely easy as it can potentially be interrupted at any time, meaning you need to account for the "not-connected" state as well as normal operation.

[drjdpowell]

BTW, if anyone is interested in Messenger Library, the best starting point is probably the Wiki page at LAVA:

https://labviewwiki.org/wiki/Messenger_Library

[David_Fanelli]

Chalk it up to days of frustration trying to modify code using Actor Framework, but I wouldn't use AF under any circumstances. If given a choice between inheriting spaghetti code and Actor Framework, I would take spaghetti code every time. At least I can trace spaghetti code to the point where I can determine where the modifications need to be made. Actor Framework obfuscates where the modification needs to be done to the point you cannot find where the modification needs to be done. This is because one Actor sends a message to another Actor, and you have to have either prior knowledge of the code because you wrote the code, or the code was effectively documented.

There is another issue that makes AF code untenable. The Queues created inter-Actor communications are both unlimited size (bad) and use a Cluster containing a Variant and a String (worse). Can anybody say "Memory Leaks"?

Before anyone says that I don't know what I am doing and AF is absolutely perfect, I did a presentation on code development at NIWeek 2019.

[BertMcMahan]

I've poked around a LOT in the AF libraries and I've never seen a string/variant pair used. If you've inherited some AF code in which someone made string/variant pairs, you've found possibly the worst possible use case for Actors. The actual AF library uses OOP messages that inherit from a Message base class. Maybe there's a string/variant pair at the base class that I've literally never had to interact with.

Are you talking about the actual Actor Framework? Or are you talking about another Actor addon?

Also... if your project can be done without actors, you should probably do it without actors. You use actors for dynamic independent processes that need to communicate with each other, in which case the obfuscation will happen regardless of using AF or some other dynamically launched library.

Is there a chance you've maybe inherited a particularly poorly coded AF project? Because "you have to have either prior knowledge of the code because you wrote the code, or the code was effectively documented." is true for any software. Yes, it's easier to trace code that's NOT dynamically launched and connected with Queues, but again, Actors don't replace regular code, they provide an asynchronous/dynamic framework that's an addition to what you'd regularly code with.

Once you're comfortable with AF (and your team is) then yeah, you can use them for non-dynamic applications, but that's also true of any tool. In other words, yes you could just run a subVI that has a queue reference on which your main code sends messages, but you still have the queues which you don't like and you've removed the ability to dynamically launch the "secondary state machine".

Disclaimer: I haven't used DQMH or JKI's QSM but I have used AF a bunch. Maybe those other libraries are more "self-documenting" than AF is. I will agree that it's very hard to trace a large Actor project without good documentation, but any large project is hard to trace without good documentation.

[ShockHouse]

I thoroughly enjoy Actor Framework, but a requirement you will want when using it is MGI's Panel Manager (From VIPM). It's a must with Actor Framework and adds a lot of useful features to base Actor Framework that you find yourself using over and over.

We use Actor Framework for our architecture, and have been since 2017 for large scale applications. We build everything into PPL's with a modular, plugin based system. That allows us to use the same architecture all over with juts a configuration file driving the look and feel. If you would like to see something like that, and see a little bit of the code, I'd be happy to show you so you can get an idea.

[wiebe@CARYA]

Stumbled upon George Box's Law (Wikipedia), stating: all models are wrong (but some are useful).

Actor framework is a model, and it is wrong. Like all models.

If (and to which extend) AF (or any other model) is useful depends on the who, how, why, and when.