Another unsung benefit of AF

[Ben_Phillips]

Rewiring your brain for the better.

There's one big thing I haven't heard mentioned about the benefits of using AF.  In the several months that I've been using it, I've become quite a bit stronger as a developer, more than any other similar period of time I can think of.  Granted, I learned OOP and message-based architecture in the process which also had a lot to do with it, but even if I didn't get all the value out of the framework itself, it still would have been a highly valuable exercise.  If anyone were on the fence about using it just from the standpoint of project risk & delivery, I would suggest that this value be added in as well to the equation.  I can almost guarantee you'll be happy you spent the effort in the end, even if it possibly held you up a little bit.

Just wrapping my head around the concepts, and implementing them in my own project, really did quite a bit of rewiring in my brain.  Very slow development at first and a lot of head scratching, but that passes.  Ironically, the painful process of fixing a fundamental flaw in my architecture (that moment of realization really _really_ sucks) was probably the best learning experience I've had in SW in years.

(Of course, this applies only if you're not already master-level.)

~~~

A little off topic but don't want to spam new threads, has anyone made a simple but somewhat substantial example of using AF?  It seems to me like a lot of people get confused by the cooler example because it shoehorns in some pretty advanced concepts, in particular the decoupled messaging.  And then it's hard to see the value in doing so because the example does very little.

Until one has a firm grasp of the simplest form of AF, or at least knows some of the Gang O Four patterns including interface, decoupled messaging is a bit much to throw at a rookie right off the bat, IMO.

The example I'm thinking of writing would just stick purely to the coupled version where each message always has a specific receiving actor (which is still way more flexible/extensible than most standard architectures).  I'm thinking of doing this to convince some others 'round these here parts to give it a go.

If someone else has done it already, though, I might just use that instead.

[MarkCG]

Agreed. I spent the past month creating a project with AF, and I can say I am very very glad I decided to do so. I had spent some time before that refactoring some older code to use LVOOP,  learned the mechanics of how LVOOP works-- dynamic dispatch, resolving the "Oh *^&(*%(@! my entire class hierarchy shows broken arrows!!!" situations. That was definitely helpful when tackling AF.  It took me a week of working with AF to get confortable with it, and more time to undestand the purpose of all the VIs and in what situation to override them... still learning a lot there. Blew my estimate for the project (not that it mattered), but definitely, definitely worth it.

I also agree with you on the cooler project-- for a newbie to AF it is very hard to see the value of all the cruft associated with OO in general, and AF in particular for such a small thing-- something you could very easily and quickly accomplish with the old "classic LabVIEW" QMH techniques.

I saw the value on OO when I was able to refactor an "alarming and protection engine" I had created with much copying and pasting on a tight deadline with a much smaller number of VIs in classes with the correct inheritance hierarchy, was able do away with the 20 case case structures all through the magic of dynamic dispatch. 

I have not done and AF project with zero- coupling yet, but, I can see the value in doing the Cooler project the way it is, with zero coupling of messages, if I wanted to be able to re-use, for example, the fan communication / direct hardware comms code on a different project without pulling in dependencies from other all the other junk in the project-- messages that belong to the higher level actor . That's at least what I understand the intent of zero-coupling is-- someone please correct  me if I am wrong.

I am curious now, to go re-visit the "Angry Eagles" demo to see what a big AF project looks like. I remember looking at it a year and half ago or so with complete befuddlement. It will probably make more sense now.

[AristosQueue (NI)]

Ben_Phillips wrote:

A little off topic but don't want to spam new threads, has anyone made a simple but somewhat substantial example of using AF?

The cooler demo is the best balance between "manageable tutorial" and "actually demonstrates power" that I have been able to build. The Angry Eagles was not written as a demo, but it is the next scale up and arguably shows the power even better, but at the cost of more "moving parts."

You are welcome to try writing a better example, but I have found that nothing small is amenable to the AF. It *wants* to work on large scale projects. It is overkill on most small things that are reasonable demos. Indeed, early on, I tried to write one small demo using AF and I ended up misleading a couple of people into thinking it should be used for individual dialog boxes (no, just keep writing those as single standalone synchronous VIs). If you can build something small enough to be digestable and large enough to show power, many people on this forum would be interested.

I am very pleased that both of you have found the AF useful thus far.

[Elijah_K]

A little off topic but don't want to spam new threads, has anyone made a simple but somewhat substantial example of using AF? 

Have you looked at this one? Measurement Abstraction Layer with AF

[justACS]

Ben_Phillips wrote:

A little off topic but don't want to spam new threads, has anyone made a simple but somewhat substantial example of using AF?  It seems to me like a lot of people get confused by the cooler example because it shoehorns in some pretty advanced concepts, in particular the decoupled messaging.  And then it's hard to see the value in doing so because the example does very little.

In theHands-On: Actor Framework exercise, you build up a much simpler version of the cooler demo.  Architecturally, it is very similar to the shipping example, but lacks some of the refinements of a more complete system.  It takes about 2 - 3 hours to complete, in manageable 20 - 30 minute segments.  There are no zero-coupled messages (but I am working on that exercise, for those who are interested).

[AristosQueue (NI)]

niACS makes a good point. I was thinking of the tutorial as still the cooler demo, but it is a much more direct implementation.