NI needs to teach more actor-oriented programming principles

[AristosQueue (NI)]

Daklu wrote:

NI has spent too much time pushing the Actor Framework and nowhere near enough time teaching people the principles of actor-oriented programming. 

*laugh*

By "NI" I assume you mean me, Allen, Eli, Brian and Nancy? Because besides the five of us, there's really not anyone else publicizing the AF within NI, and very few who would even know what it is if you asked them about it. What more do you want us to say about it?

(Branched from https://decibel.ni.com/content/thread/16763?start=15&tstart=0 )

[David_Staab]

Well, yeah. Y'all are public faces of NI; and Brian, Eli and Nancy's jobs are to preach best practices for LV software development. So he absolutely means "NI" when he talks about your efforts to solicit AF.

[AristosQueue (NI)]

As long as we're clear about who we're talking about. 🙂

Still, my question stands: what more would you want us to say? I've communicated out -- in posts, in the white paper (which ships with the templates in LV 2012), and in the hands-on session content -- as much as I know about actor-oriented programming.

[Brian_Powell]

I can assure that Nancy and I haven't been pushing the AF, so I guess that just leaves the three of you.

Besides the people, there is the prominence in the product.  In the Create Project dialog, for example, it shows up more prominently than the DAQmx projects such as "Finite Measurement" and "Continuous Measurement and Logging".  I vaguely recall lobbying to not do this, and if I did, I lost.

Don't get me wrong--if you need the AF, then we encourage you to use the AF.  It's just that many customers can't correctly answer the "if you need the AF" part of that.

[AristosQueue (NI)]

Brian_Powell wrote:

I can assure that Nancy and I haven't been pushing the AF, so I guess that just leaves the three of you.

Ah. I thought you'd been using it at some point for a couple of your accounts. Alright... strike your names. 😉

By the way, Brian, have you considered using the Actor Framework? It's a great tool for...

*ducks*

[David_Staab]

FWIW, I think there are several discussion threads in this group that present the questions you should ask yourself when deciding whether you need AF (and how to use it without hurting yourself). The information is scattered and buried in these threads, but it's there.

I hope my topic submission gets accepted for NI Week, so I can gather all that info and put it into a single coherent presentation for people to refer to.

[wirebirdlabs]

David_Staab wrote:

FWIW, I think there are several discussion threads in this group that present the questions you should ask yourself when deciding whether you need AF (and how to use it without hurting yourself). The information is scattered and buried in these threads, but it's there.

The tough part; it's hard to verbalize these questions (or even be aware they exist) unless you've been there and back again down a few right, but mostly wrong paths. (Related: I would love to hear your NIWeek topic; I hope it gets accepted also.)

Earlier today I was looking at benchmarks of web frameworks, and based on the charts, it's *clear* which framework you should choose for your next web project, yeah?? Brrrr... wrong. The benchmarks focus on metrics that're probably way outside the operational requirements of most application specs; a couple of the most popular, best-documented (Rails and Django, notably) are presented as *terrible* performers in this chart.

Considering any framework as a monolith, without evaluating how easily you can randomly access its merits applicable to your domain, is a mistake. (If the framework does not provide random access to its merits by unnecessarily coupling them, this just means the framework can be improved)

That said; I have no problem with NI championing Actor Framework as a monolith without strong focus on discrete AOD principles. At worst, it gets devs on the hook to some fantastic concepts, and once they start down the path of implementing AF, can start to figure out on their own through trial and error what's important for their app domain. As long as they're aware of the channels for sussing out their AOD quest (this community group and LAVA), everyone wins. yeah?

[David_Staab]

JackDunaway wrote:

I have no problem with NI championing Actor Framework as a monolith without strong focus on discrete AOD principles. At worst, it gets devs on the hook to...figure out on their own through trial and error what's important for their app domain...everyone wins. yeah?

Somewhere in the world, a Project Manager just got a cold chill down his spine and doesn't know why.

[Brian_Powell]

David_Staab wrote:

JackDunaway wrote:

I have no problem with NI championing Actor Framework as a monolith without strong focus on discrete AOD principles. At worst, it gets devs on the hook to...figure out on their own through trial and error what's important for their app domain...everyone wins. yeah?

Somewhere in the world, a Project Manager just got a cold chill down his spine and doesn't know why.

I know I did, but I know why.  At worst, a novice to intermediate programmer fails and blames LabVIEW for his failure, because that's easier than accepting that he doesn't have the necessary skill (e.g., training and experience) to be successful.

[Daklu]

AristosQueue wrote:

By "NI" I assume you mean me, Allen, Eli, Brian and Nancy?

Nope, I actually meant NI as a company, because there appears to be--to us external viewers--a widespread effort to promote the AF.  If there really isn't a widespread effort to promote it then you, Allen, and Eli have done a fabulous job of getting the word out.

AristosQueue wrote:

What more do you want us to say about it?

To repeat what I've been saying for (what seems like) years...

<minor rant>

Explain actor-oriented programming using concepts people are familiar with.  The core component of any actor is the logical thread that does the message handling.  People know what a message handler looks like--heck, the string/variant QSM is probably the most widely (ab)used implementation pattern in Labview.  Conveniently, you can implement an actor with code that looks an awful lot like a string/variant QSM.

Contrasting a typical QSM implementation (complete with reference based data storage and disorganized control) with an actor-based (not AF) implementation of the same thing using familiar programming concepts is (imho) the best way to get people to focus on the principles of actor-oriented programming.  It's much easier to demonstrate (for example) the inherent race condition in a sender-side filter implementation when people can actually understand what the code is doing.

Granted, teaching AOP is not something that can be accomplished with one or two white papers, and admittedly I haven't read all the material you've put out.  I've been evangelizing AOP for a couple years (even though I didn't fully recognize it as AOP early on) and trying to get people to focus on principles so they can use the framework effectively to solve their specific problem.  Given that I don't have the prestige of an NI email address and everything AOP-related I've seen coming out of NI is geared specifically for the AF, it feels like I'm spending a lot of my time spittin' into the wind.  *shrug*

</rant>