Leaderboard

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

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.

The library operates directly on the database file, no ODBC.

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>