Is a baked-in Actor Framework on the drawing board?

[Bob W Edwards]

This question aimed at NI: There are many frameworks some stable and others still emerging for building an application from messaging Actors - which is great. They all of them suffer from one overriding issue, that of being more complex than one could wish for. One of the basic aims of LabVIEW was to allow non-programmers to achieve their goals with a minimum of fuss. None of the existing frameworks can claim this, so the user stays focussed on the application and doesn't get diverted by the complex syntax.

Is it likely we'll see a baked-in messaging Actor feature with a simple api in LabVIEW sometime? OR are we better off continuing to refine the above frameworks for a little while longer?

Regards, Bob (Being retired I use home LabVIEW at the moment but looking forward to the free community edition next year)

[Aristos Queue]

A first-class, baked-in, messaging framework of some sort is on my personal roadmap. I have multiple design documents, use cases, customer feedback, etc.  It is priority number two on my list of future language advancements that I want to work on.

But I have yet to convince NI that it is a priority.

So, for now, the Actor Framework remains my team's best effort -- through the support in the project tree and the documentation tools -- to create a messaging system with minimal diversion into syntax. It is a mixed bag of a success. It has inspired several other similar frameworks, each with its own tradeoffs.

Even if I were to convince The Powers That Be, such effort would almost certainly be directed to LabVIEW NXG, not LabVIEW 20xx -- arguing for 20xx is an even harder argument to win. I would recommend continuing to refine the various frameworks for the foreseeable future. That's my personal opinion from the trenches. If something better is important to you, please use various customer channels to communicate your desire to NI. The Powers listen better to customers directly than to me saying things on behalf of customers.

[X___]

No interest in NXG from this neck of the woods would be the feedback to the Powers that Were.

[DTaylor]

4 hours ago, Aristos Queue said:

... It is priority number two ...

What's number one?

[ShaunR]

1 hour ago, DTaylor said:

What's number one?

Hopefully TLS1.3 

[smithd]

13 hours ago, X___ said:

No interest in NXG from this neck of the woods would be the feedback to the Powers that Were.

Lol. Sorry for sidetracking, but I tried to get it to even open and it crashes on my machine. If you believe a KB, at some point someone before me installed a beta version of nxg on what is now my laptop (seems unlikely). The fix is to uninstall nxg, uninstall ni package manager, "Remove any supporting NXG files in the root directory, removing any trace of LabVIEW NXG from the machine" and reinstall everything. I asked NI support what "the root directory" is I'm supposed to delete NXG stuff from and they told me it meant the C drive 😕. Find an unspecified leftover NXG file somewhere on the C drive and delete it. What a joke.

11 hours ago, ShaunR said:

Hopefully TLS1.3 

Lol

Edited January 3, 2020 by smithd

[Aristos Queue]

a) TLS support would be a library, not a language feature.

b) I wouldn't expect to have anything to do with such a project... networking protocol code is a long way from my areas of both knowledge and interest.

c) Your timing is impeccable. Status changed to In Development (should've been set that way six months ago... we missed it in the list):
https://forums.ni.com/t5/LabVIEW-Idea-Exchange/SSL-TLS-Support/idi-p/3314187

[mechtroid]

I'm guessing #1 is some sort of native Character Lineator framework.  It'd solve a lot of busywork when serializing labview data for other languages.

[Aristos Queue]

14 hours ago, smithd said:

Lol. Sorry for sidetracking, but I tried to get it [NXG] to even open and it crashes on my machine.

NXG is not my area of concern at this time. I can see it approaching in the rear view mirror, but my job is to hold the accelerator down on the current product as long as possible... NXG is a much larger dev team... they'll overtake my team eventually... but today isn't that day. 🙂

[Aristos Queue]

22 hours ago, DTaylor said:

What's number one?

Well, it isn't interfaces... those are at "priority zero... in beta... conditions look good for launch in T-minus 4.5 months."

[DTaylor]

26 minutes ago, Aristos Queue said:

c) Your timing is impeccable. Status changed to In Development (should've been set that way six months ago... we missed it in the list):

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/SSL-TLS-Support/idi-p/3314187

Finally!

4 minutes ago, Aristos Queue said:

Well, it isn't interfaces... those are at "priority zero... in beta... conditions look good for launch in T-minus 4.5 months."

!!! Is there anywhere we can read about specifics?

You've given us priority #0 and #2, are you unable to share #1?

[Aristos Queue]

11 minutes ago, DTaylor said:

Finally!

!!! Is there anywhere we can read about specifics?

You've given us priority #0 and #2, are you unable to share #1?

Unwilling, not unable. I'm proposing it as a research vein over the next couple weeks. If The Powers tell me there's zero chance, I won't even bother getting into it ... it's a brainstorming rabbit hole that I think has benefit, but few others agree with me, even among customers. If I get a go ahead for it, I'll probably be discussing it at the CLA Summit in September.

[Aristos Queue]

17 minutes ago, DTaylor said:

!!! Is there anywhere we can read about specifics?

https://ni.com/beta

And there's a CLA Summit presentation from September that I gave that is videotaped and archived somewhere in the CLA forum... I don't have that link handy at the moment.

[ShaunR]

2 hours ago, Aristos Queue said:

a) TLS support would be a library, not a language feature.

b) I wouldn't expect to have anything to do with such a project... networking protocol code is a long way from my areas of both knowledge and interest.

c) Your timing is impeccable. Status changed to In Development (should've been set that way six months ago... we missed it in the list):
https://forums.ni.com/t5/LabVIEW-Idea-Exchange/SSL-TLS-Support/idi-p/3314187

It was a gentle reminder of a question I asked you a couple of months ago

So will the distributed LabVIEW OpenSSL binaries be updated to  1.1.x anytime soon? (that's the version  minimum to support TLS1.3) Can anyone confirm the version in the Beta?

1 hour ago, Aristos Queue said:

If The Powers tell me there's zero chance, I won't even bother getting into it

To be honest. I'm surprised you aren't one of "The Powers". You've done your time and given impeccable service.

 

Edited January 3, 2020 by ShaunR

[Bob W Edwards]

Aristos,

Thanks for the insight into the status of Actor programming within NI. The case for building Actors into the language would have to be compelling given the amount of work involved. I was just curious to know if a more elegant feature was imminent. For now I'll continue with Messenger Library in my little retirement project (a software defined ham radio).

Bob G4BBY

[DTaylor]

On 1/3/2020 at 1:24 PM, Aristos Queue said:

Unwilling, not unable. I'm proposing it as a research vein over the next couple weeks. If The Powers tell me there's zero chance, I won't even bother getting into it ... it's a brainstorming rabbit hole that I think has benefit, but few others agree with me, even among customers. If I get a go ahead for it, I'll probably be discussing it at the CLA Summit in September.

Sounds interesting. I'd love to hear what it was even if it gets shot down.

Do you have any stories of ambitious/controversial proposals that never had a chance?

[Aristos Queue]

3 hours ago, DTaylor said:

Do you have any stories of ambitious/controversial proposals that never had a chance?

There’s three that come to mind. 
 

No one but me liked my Recursion structure node as an alternative (improvement, in my opinion) over just allowing a VI to call itself as a subVI. I took a rather radical position that recursion should have a compiler-provable base case as part of its declaration, and that raw function recursion, though critical in math, is not healthy in a programming environment because compilers cannot really prove (in most cases) that it doesn’t blow up the stack. But every other language just has recursion... my structure node was too different. 

I had a really bad design for sets and maps back in 2001 that I pushed hard for: a complete by-reference design that I’d worked out. That one got me a lecture from Jeff K that rings in my ears to this day on the value of by-value. There was a good-natured-but-insistent afternoon of all the senior devs basically taking turns showing all the really bad architectures my API enabled until I finally got the point. 🙂 Eighteen years later, I lead the effort to put the by-value API in. 
 

I have a bunch of NXG designs that were too radical to gain traction. Most notable of those was formalizing the error propagation and handling to wipe error wires out of most diagrams. I and two other researchers worked on that for almost a year, and we were really excited by the design, but the shipping timetable didn’t allow us to do it... so they implemented the same error cluster. We were told that we could do it later, but now it would be a breaking diagram change... bigger hurdles. Unlikely to happen now.  
 

There’s more. Those are the ones that come to mind easily. 

[Bob W Edwards]

So, very interested to see Jeff Kodosky's GLA 2020 presentation on youtube on A Visible Actor Framework. I hope it gains traction, as it would do much to lower the 'difficulty curve' when attempting to write large applications. Simple reusable actors where OOP is optional, not mandatory, would be great.

[ShaunR]

On 12/11/2020 at 6:33 PM, Bob W Edwards said:

So, very interested to see Jeff Kodosky's GLA 2020 presentation on youtube on A Visible Actor Framework. I hope it gains traction, as it would do much to lower the 'difficulty curve' when attempting to write large applications. Simple reusable actors where OOP is optional, not mandatory, would be great.

It's a good idea but it's an awful implementation. You can smell that it's awful from the amount of infrastructure replication from diagram to diagram so eventually it all looks the same with minuscule differences. That's *not* reuse! Scripting isn't the answer here.

A better approach would be similar to the "Named Events" that I once played with.

Of course, I don't have the ability to draw wires between the producers and subscribers in there that Jeff can do,  but the Event Structure becomes housing for your code populated with the appropriate events and data terminals dependent on your message-either in another loop on the diagram or in a completely separate VI (we'll call Actor ).

So. With the above in mind. Say we didn't even want to have the VIM node (which is just really defining the message or, more practically, the user events and data terminals that appear in the Event Structure) and we could just pop-up on the Event Dynamic Registration terminal and define our message. That could then be available throughout all our code (we can argue about scope later).

So Like Jeff, 1 is the "expanded" code and 2 is the iconised abstraction.

Now. Of course. Jeff uses wires and we could use wires here too to represent the message paths between the loops and icons if we were NI devs. But if we are going to use another interface, lets just use it to view the message paths.

Rather than straight-jacketing the developer to the alternate view and lot's of [slowly scripted] boiler plate code, we are viewing the actual programmed code and can debug the messages. (the blue dot is the probe and the probe content are on the right). All the complexity has been hidden and simplified-which is what we want.

Now we have a system that is in the same spirit as the hierarchy and class windows and very little boiler plate code. Additionally, "actors" can be launched dynamically and we can still debug them. The LabVIEW developer only needs to lay down a loop with an event structure and pop-up on the Dynamic Registration terminal to create or subscribe to messages. When subscribing, the events and the data types are propagated in the structure just like normal user events. We could even use the Dynamic Registration on the right side to send messages back to the producer or other subscribers. If the latter were the case, then the producer in the examples shown, could simply be a value wired to the right-hand side Dynamic Terminal of an event case (in the timeout case with 10ms wired) instead of the Generate User Event shown.

Edited December 14, 2020 by ShaunR

[ShaunR]

On 12/13/2020 at 12:34 AM, ShaunR said:

he LabVIEW developer only needs to lay down a loop with an event structure and pop-up on the Dynamic Registration terminal to create or subscribe to messages.

Thinking a bit more about this. We already have an editor where we could add the messages rather than usurping the dynamic terminal. After all. It's really just pulling in and simplifying dynamic events so that no primitives are needed and adding a viewer for the message paths. The only outstanding question is what do we do about generating the events to remove the last primitive (Generate User Event)?

The more I look at this, the easier it becomes to implement 

[Bob Edwards G4BBY]

 

Yes, Jeff Kodosky's proposal was still an 'add-on' supported by scripting with whatever limitations that brings. However it's heartening that one of the founders is thinking about the issue - I bet it's not the only idea he's had on the subject either.

The event structure radically dropped the complexity level of LabView programs. Added features to event structure for Actor programming might be part of the solution.

I guess it all hinges on where NI is going to take LabView, post-NXG. Adding OOP was NI's last 'big deal' for LabView and that was sometime back. I read (via the critics on this forum) that NI could still do with something reasonably big to revive relevancy to the programming community. Might this be it?

The 3rd party Actor system designers (and the 'Actor Framework' people within NI) have done a fantastic job exploring what works and what doesn't - why don't they and NI get their heads together to agree on a common, simple syntax for built-in Actor programming? There's a wealth of experience out there in Actor application and we would be more likely to end up with something usable, if their views were heard or they were involved.

A built-in Actor syntax should have, as it's number one goal, the promotion of a new breed of 'Actor library' circulating between users as a higher level of IP exchange with a common api. At the moment 'Actor Framework' authors can't exchange Actors with Delacor authors who can't exchange with 'Messenger Library' authors etc. The upshot is that the Actor community and IP exchange is fragmented, like we saw before  built-in OOP came along.

In my many years of studying Labview from writings on the internet, a fair number of text books and so on, it has always struck me that the language did not scale well beyond the confines of the computer monitor - a complex state machine at best. You just don't come across that many non-Actor articles on writing modular applications without 'ugly' coupling. The time feels ripe to change that. Actor fundamentals are simple, adding built-in Actors fills a need to facilitate an elegant,  higher level modularity; it's time that was reflected in the 'wires'.

<Steps down of soapbox>

Edited December 15, 2020 by Bob Edwards G4BBY

[ShaunR]

7 hours ago, Bob Edwards G4BBY said:

why don't they and NI get their heads together to agree on a common, simple syntax for built-in Actor programming?

Well. I settled on string messages with a syntax similar to SCPI .The issue then becomes how to disassemble the strings and turn them back into the types. When I demo'd the above concept using "Named Events" (Anyone remember the HAL Demo?) I had to use a split-string VI with case statements in the Event structure to do this. That could be alleviated by LabVIEW's in-built cluster mechanics in the Event Structure but then we move away from strings to clusters. So whilst strings would flatten the interoperability, clusters would bring us back to the lack of interoperability that you describe.  I've maintained for a long time that strings are the ultimate variant and they can be transmitted across networks and/or to other languages to boot.

In this paradigm I chose string formats of the form SENDER>TARGET>OPERATION>PAYLOAD (e.g. "MAIN>SOUND>PLAY>FILE>operatio.wav"). The first two elements are the source and destination - more specifically the Sender's VI name and the intended Recipients VI Name. That could be hidden and removed with the proposed event implementation above since LabVIEW would have that knowledge and it is used used purely for filtering the messages (events are one-to-many).

It also meant that I moved away from QSM's to EDSM's (Event-driven State Machines) and "Services" and "Listeners". Services provide application-wide functions and access to resources that were typically singletons such as Comms, logging, database access , Sounds etc while Listeners simply observed the messages and do their own thing, often utilising the Services. So I guess you could consider Services and Listeners as sub-classes of the generic "Actor" term. The result of that is you end up with standard Services with no static linking to the application-pluginable, if that's a word -  and could be imported to other projects just by laying the icon in the main diagram or dynamically loaded (dependencies excepted, of course). Once loaded, the developer just had to send it messages to use and subscribe to messages to get info and feedback. They could also be tested and used in isolation which makes LabVIEW life so much easier. 

As an example. you can clearly see the Services (along the top) in the following application that I started a while back (and may pick up again with the news NXG is shelved). The Listeners are the pages in the Tab control.

 

Edited December 16, 2020 by ShaunR

[Neil Pate]

At this point we should be looking to remove things from Core LabVIEW, not adding them. LabVIEW already carries way too much baggage.

I am strongly against NI trying to push YAAF (yet another actor framework) onto us.

[ShaunR]

30 minutes ago, Neil Pate said:

At this point we should be looking to remove things from Core LabVIEW, not adding them. LabVIEW already carries way too much baggage.

I am strongly against NI trying to push YAAF (yet another actor framework) onto us.

If they removed classes I wouldn't be too upset  Good trade-off.

[Neil Pate]

5 hours ago, ShaunR said:

If they removed classes I wouldn't be too upset  Good trade-off.

I think you might be in the minority here. How about I offer you shared variables instead?