Actor Frameworks - worthwhile?

[BowenM]

I have never used actor frameworks before and just started doing some research on them. My first impression is that they seem an overly complicated solution in almost all cases. About the only time I could see a solid use is if you are writing a truly massive application (hundreds of Vis).

So, my question is: those of you who have written programs around action frameworks, was it worthwhile?  Did you find real benefit over queued message handlers?  And, was the implementation harder or easier than just using queues?

I’m about to start a somewhat large project, and am trying to decide the best design pattern for it.

Thanks,

-M

[tyk007]

Speaking to the Actor Framework in LabVIEW specifically - it is a complex beast and takes time to learn. One of the reasons for the complexity is enforcing a certain "pattern" of development (architectually speaking) in order to reduce complex multi-tasking issues that can easily occur in other architectures such as QSMs. This tends to end up producing more VIs and more interactions between systems that can be difficult to describe but to a certain extent the "hard yards" have been considered and done for you in the framework.

There is ownership and drive from NI to support and further develop the framework with each new iteration of LabVIEW along with a community of people using it.

It is hard to recommend without a good understanding of your experience. If you are comfortable with object oriented programming, and LabVIEW classes in general, it might make a good learning opportunity on a small project with limited risk. Large project or high commerical risk - you might be better off postponing the learning curve to another time.

[Hooovahh]

Someone at NI R&D told me that the purpose of the Actor Framework was not to replace all other design patterns, but instead give those developers who don't have a general purpose framework something to work with.  I took that to mean if you have something that works, and you are comfortable with, then Actor might not be for you.  On the other hand I've heard of others throwing away their custom frameworks for Actor because NI supports it.  And if that works for them, good.  As for me, I'm quite comfortable with my own actor implementation.  I'll continue to try out the Actor Framework every so often, and look for ways that my implementation can improve. 

Oh and In my mind massive applications are something like 10,000 VIs.  I have several projects I'd consider medium in size that are over 2,000.  If you went with the Actor Framework and OO you'd have lots more.

[BowenM]

Thank you both for your replies. I kind of got the impression that was the case, but it is always good to have extra feedback. What I use now works, and I will leave learning it for another time.

A medium sized application to you is 2k VIs?  That is an odd thing to think about. To me it is anything over about 400. Guess preception shifts as you become more proficient and start building ever larger applications.  Had you asked me two years ago, a medium sized app would have been 50 VIs.

[Wart]

I do almost all of the development where I'm at, and I try to avoid using AF because I think it sets the bar too high for the next person that fills my shoes.  It's such a new and complicated framework that it'll be difficult to find someone with that level of knowledge that can come in and just get straight to work.

I've used it a little bit, and it's really a slick idea.  I'd love to use it for everything, but I already see so many developers that don't know LVOOP that I almsot feel a little bad to use it for everything (as appropriate).  I try to tell myself that setting the hiring bar at the LVOOP level makes sure that someone good comes behind me. 🙂

[Hooovahh]

---

@Wart wrote:

I do almost all of the development where I'm at, and I try to avoid using AF because I think it sets the bar too high for the next person that fills my shoes. 

---

Changing topics a bit, my recommendation is to not limit yourself, for your current employer.  You aren't trying to screw them over by obstrufication, or making it intentionally more difficult for them.  You are using the standard tools by NI to develop an application which I'm guessing is your job.  Your company trusts your judgement in application development.  I see worrying about who they are going to find to replace you when you are gone as a non-issue.  Maybe I'd feel different if I were an employer, but then I'd say it is my fault for not getting more involved in the technologies my employees are using.

[nyc_(is_out_of_here)]

---

@Hooovahh wrote:

---

@Wart wrote:

I do almost all of the development where I'm at, and I try to avoid using AF because I think it sets the bar too high for the next person that fills my shoes. 

---

Changing topics a bit, my recommendation is to not limit yourself, for your current employer.  You aren't trying to screw them over by obstrufication, or making it intentionally more difficult for them.  You are using the standard tools by NI to develop an application which I'm guessing is your job.  Your company trusts your judgement in application development.  I see worrying about who they are going to find to replace you when you are gone as a non-issue.  Maybe I'd feel different if I were an employer, but then I'd say it is my fault for not getting more involved in the technologies my employees are using.

---

I agree with Wart. You are intentionally limiting the next person to fill your shoes.

If it was me, I would make very certain that your emp;loyer truly understands what you are doing.

And from my experience, almost all employers won't, unless you are working for an NI Alliance member.

[Wart]

---

@Hooovahh wrote:

---

@Wart wrote:

I do almost all of the development where I'm at, and I try to avoid using AF because I think it sets the bar too high for the next person that fills my shoes. 

---

Changing topics a bit, my recommendation is to not limit yourself, for your current employer.  You aren't trying to screw them over by obstrufication, or making it intentionally more difficult for them.  You are using the standard tools by NI to develop an application which I'm guessing is your job.  Your company trusts your judgement in application development.  I see worrying about who they are going to find to replace you when you are gone as a non-issue.  Maybe I'd feel different if I were an employer, but then I'd say it is my fault for not getting more involved in the technologies my employees are using.

---

If I was ever in a situation where using AF was obviously the correct thing to do, then I'd probably go ahead and use it.  Right now it's more of a, "Well that might be nice to have going forward, but we can continue with what we have now." 

If I did nothing but write LabVIEW code, then I could feel better about forcing my employeer to hire someone with enough experience that either already knows AF or could easily pick it up.  That's a relatively small subset of LabVIEW developers right now.  Or at least I feel like it is.  My job is to put my employeer in a position to have success going forward.  The applications I write and maintain will be used for a long time, and the last thing I want is someone coming in and adding more of the stuff I've had to work hard to fix (stacked sequence structures, diagrams multiple monitors tall/wide, etc).  When people don't understand what they're looking at, my opinion is that they'll end up writing bad code on top of it.  That's bad for the company, and I recognize it has no bearing on me when I'm somewhere else.  If I got hit by a bus today, I know who would have to maintain my code in the immediate future.  For that person LVOOP is already a couple of levels about his or her head.

[nyc_(is_out_of_here)]

---

@Wart wrote:

---

@Hooovahh wrote:

---

@Wart wrote:

I do almost all of the development where I'm at, and I try to avoid using AF because I think it sets the bar too high for the next person that fills my shoes. 

---

Changing topics a bit, my recommendation is to not limit yourself, for your current employer.  You aren't trying to screw them over by obstrufication, or making it intentionally more difficult for them.  You are using the standard tools by NI to develop an application which I'm guessing is your job.  Your company trusts your judgement in application development.  I see worrying about who they are going to find to replace you when you are gone as a non-issue.  Maybe I'd feel different if I were an employer, but then I'd say it is my fault for not getting more involved in the technologies my employees are using.

---

If I was ever in a situation where using AF was obviously the correct thing to do, then I'd probably go ahead and use it.  Right now it's more of a, "Well that might be nice to have going forward, but we can continue with what we have now." 

If I did nothing but write LabVIEW code, then I could feel better about forcing my employeer to hire someone with enough experience that either already knows AF or could easily pick it up.  That's a relatively small subset of LabVIEW developers right now.  Or at least I feel like it is.  My job is to put my employeer in a position to have success going forward.  The applications I write and maintain will be used for a long time, and the last thing I want is someone coming in and adding more of the stuff I've had to work hard to fix (stacked sequence structures, diagrams multiple monitors tall/wide, etc).  When people don't understand what they're looking at, my opinion is that they'll end up writing bad code on top of it.  That's bad for the company, and I recognize it has no bearing on me when I'm somewhere else.  If I got hit by a bus today, I know who would have to maintain my code in the immediate future.  For that person LVOOP is already a couple of levels about his or her head.

---

It is a very small subset of LabVIEW "developers" right now.

I have found that some LabVIEW developers who work exclusively with LabVIEW specificially the ones who attend NI Week every year have a myopic view of the talent pool out there.