Leaderboard

Funny you mention this. Here's a slide from the most recent version of my Fundamentals of AOP presentation.

Y'all sometimes ask me, "AQ, why are you so eager for LabVIEW NXG?" Language extension is the biggest answer. The code layers of NXG are far more amenable to language extensions. I've got an 80-slide PPTX on actors as first-class citizens: no queue management, no classes for messages but retaining type safety, no weird error codes, easy handling of parallel loops without custom stop signals, direct execution testing, debug monitoring... but I just don't see it happening in LabVIEW. The compiler simply isn't sophisticated enough to take a high-level diagram and generate the code implied by it -- not enough separation between source model and execution model. NXG retains the existing execution model and builds a separate source model, which means the transforms possible in the compiler are waaaay more extensive. And mine is not the only proposal on the table. I work with a team full of people who have alternate diagrams that bring the actor model more directly in line with data flow, or introduce various other types of dataflow. Did you see the Multi-Rate Diagram that was in LabVIEW Comms when it released? Sadly discontinued for various reasons, but it provided a totally different set of rules for how an upstream node triggers a downstream node. Likewise, Rebar is a different model of computation that can compile in the NXG compiler. You've seen what we can do with channel wires already in LabVIEW... we can go sooooooooo much further in LabVIEW NXG. PS: I was torn in the poll... "Do I choose 'Actor Framework' or do I choose 'my own framework'?" 🙂

I've been looking at the GCentral site and visited the Package Index page. While I find it a good initiative I see here the same problem that makes me loath browsing the NI site for products. I'm interested in the list of packages mostly yet half of the screen is used up by the GCentral logo and lots and lots of whitespace. I may be a dynosaur in terms of modern computer technology and not understand the finesse of modern web user interface design, but a site like that simply does not make me want to use it! Maybe this design will be beneficial to me in 10 years from now when my eyesight has detoriated so much that I won't see small print anymore but wait, the text in the actual list is still pretty small, so that won't help at all. It's also not because of the much acclaimed fluent design. The size of the actual screen stays statically the same no matter how I resize the browser window. This kind of web interfaces makes me wonder where we are all heading to. Design above functionality seems to be the driving force everywhere.

@Jim Kring, it seems to me that the export of the code has gotten a positive response from the community. However I may be wrong. If anyone has any opinion either way, please come forward. As you can see in this thread, it appears the community has rallied around this effort. This is why I emailed you to come here and share your thoughts. In the past, OpenG was a great venue to showcase how a bunch of passionate LabVIEW users can come together and collaborate on something useful. The passion is clearly still there, as shown by the numerous discussions here. The general coding community has moved to Git with GiHub being the hub. This seems like the logical next step. Who knows what this initiative will lead to. However, I’m expecting that placing OpenG in a neutral GitHub repo will provide the spark and the tools to facilitate open collaboration, then the community can drive the future. The community is full of smart people who have a desire for clean tested code. And if issues come up, LAVA discussions (or GitHub issues) are there to hash things out. When LAVA offered to host all OpenG discussions back in 2011. it was clear that the community wanted to help. When @jgcode put his standards together for how code should be discussed at that time, It was an exciting time. Since then, many people have come forward with offers to add new code into OpenG and fix bugs. For example @drjdpowell first offered to include his awesome SQLite toolkit for inclusion into OpenG. He got no response either way. It’s a shame to have a platform and forums to allow people to post and discuss OpenG code and then ignore it. If you have ideas on what the future of OpenG is. I’m hoping it’s to be more transparent and inclusive. Providing the tools, resources and some safety checks along the way, is the best way to facilitate passionate individuals to dive in. Do you think keeping the status quo of the past 10 years makes sense? It seems to me that the community disagrees. What do you think?

I think the main problem is that most people confuse frameworks with architectures. People tend to pick one framework then try to shoe-horn in incompatible features. The obvious one is the difficulty in sequencing actors in the actor framework. It's a concurrent paradigm so is very resistant to sequencing and all sorts of contortions have to be realised to make it useful in certain circumstances. This is why I like SOA. A service can use any of the frameworks that fit the requirement for that service and the system state is external to the services. Many, if not all, of the frameworks embed the system state inside the framework and therfore you run into problems when, for example, you need to sequence concurrent operations (AF) or concurrently execute sequential operations (QMH). Because of that you end up with silly things like "Promises".

Your right, the question of strict versus weak typing is an important question and involves trade offs, and different frameworks make different choices. I, in using Messenger Library, seem to spend almost no time bothered by problems caused run-time type mismatches, so I am not much impressed by the edit-time type safety if it comes with the negative trade offs of requiring large scripting tools to work productively. Why that is might be a long discussion about other features of how I code, and what information is put in a message. I've tried to point out before that code frameworks support mental frameworks, sets of guidelines that work together, and it can be difficult to compare code frameworks because it is hard to full grasp the full set of its mental guidelines. You found that yourself when AQ's strong criticism of State-Machine-Objects didn't really move you, because you just have to "impose some rules when developing with this framework".