Daklu

Here you're talking about the complexity of an application that uses the framework, in which case I agree the application's complexity isn't necessarily increased by the unused framework options. (This is especially true if the person inheriting the code has previously used the framework. I'm not convinced it's true if the inheritor knows nothing about the framework.) I'm talking about the complexity of the framework itself (which is also what your original comment seemed to refer to) and how easy it is to build a mental model of how the thing works. More behavioral exceptions and options make it more difficult to understand, which I equate to being more complicated. I completely agree how an option is presented can dramatically impact how a user perceives the complexity. I disagree optional terminals add zero complexity to the framework. It may be an insignificant amount of additional complexity for those who see it and mentally discard it immediately, but even in that extreme case it still takes a non-zero amount of effort to process that option and decide where it fits in the mental model we're creating. While learnability and complexity are not exactly synonymous, in my mind they're at least very closely correlated. What kind of complexity are you referring to?

I disagree. While it is entirely realistic to build apps without using priority queues, having this option available does add complexity to the AF and DQMH. If you show someone a regular piano and an electric piano/synthesizer and ask then which is more complicated, what do you think they'll say? Having more optional features available, especially when they're easily discoverable by users, adds complexity. Users are going to spend a non-zero amount of time considering those optional features and adjusting their mental model of how the framework works.

The AF priority queue does enforce ordering. The DQMH priority queue does not. (I'm not advocating for one or the other... personally I think priority queues are a bad idea.)

That's a great example, and I'll add that I think your conclusion holds even if you didn't look at the implementation. On the surface the conceptual model presented by the AF seems more complex. It has multiple priority levels available whereas the DQMH has only a single priority level. But the AF implementation behaves predictably--messages sent in order (with the same priority level) execute in order, while the DQMH implementation may not. On the other hand, I think Fab strongly recommends only sending Exit/Abort messages as priority, and as long as one follows that rule you could argue DQMH is simpler. ------ Thinking about it a bit more, in my mind there are at least three different kinds of complexity: Code complexity: How hard is it to understand a block diagram. Behavioral complexity: How hard is it to understand how a single component will behave under various conditions. (Or how complicated is the conceptual model of the component.) System complexity: How hard is it to understand how changes in one part of a system affect other parts of the system. Seems to me the DQMH priority message is simpler than the AF priority message in 1 and (arguably) 2, but takes a huge hit to 3 when multiple priority messages are sent.

Yeah, I agree with you for the most part. Maybe that's because the applications LV developers are typically asked to write are a small fraction of the kinds of software that can be written. My projects almost always boil down to some sort of machine control or acquire/analyze/present. (I've not heard of anyone building a load-balancing web server, a cool 3D game, or a spreadsheet using LV.) Eh... that may be true for some of them. There's an inherent impedance in connecting non-AF code to AF code that tends to encourage people to use AF for the entire app. (At least there was last time I looked into it 6-7 years ago. It might be better now.) Most of frameworks listed I haven't used enough to evaluate how easy it is to connect to them with non-framework code. (DQMH, Aloha, DCAF, etc.) I agree that it would be nice if it were easier to connect components that use different frameworks. It certainly can be, but it's not necessarily the case. Remember that that app has to satisfy all requirements, not just the functional requirements. I believe any technical problem that can be solved by LVOOP can also be solved without it. But my projects also have requirements like the number of hours I can spend developing it and it must be maintainable by John Doe. So, I choose to use LVOOP because I don't have to build the functionality I'm looking for and John Doe doesn't have to learn my custom LVOOP-ish code. I agree the terminology is bad, but you're getting too hung up on the common meaning of "accidental." In this context it is used simply as an antonym of "inherent complexity." (I've also seen "inherent complexity" referred to as "essential complexity," if that helps conceptualize it.)

1. What application architecture do you use for higher-level organisation? I'm going to be pedantic and change my answer, since the options listed are frameworks, not architectures. 😋 The architecture I most frequently use is the "hierarchical actor architecture." If one were to ask for a little more detail, I'd say "hierarchical actors with asynchronous name-data messages."

The things I've read always refer to it as "accidental" complexity, but you can think of it as "unnecessary", "incidental", or simply "non-required" complexity. It's just complexity in a system that isn't a necessary to meet the requirement (both functional and non-functional) of the system. System complexity is a subjective evaluation, so these are more abstract ideas than concrete rules to follow.

Hmm... I'd slightly change that to say the payoff of a good architecture is in managing an application's inherent complexity. IMO, the whole point of a framework is to increase productivity, so a "good" framework is one that does that. Naturally, the frameworks we're talking about here are neither wholly good or bad, just good or less-good for a specific set of project requirements. I disagree with the claim that a good framework makes complex applications simpler. An application with complicated requirements is going to have some minimum amount of inherent complexity. The best a framework can do is help eliminate accidental complexity. However, I believe minimizing accidental complexity is more a product of good architecture than a good framework. One of the reasons I don't use frameworks is because they force developers to fit the application into the framework and tend to impose architectural decisions that are better left to the system designer. The best frameworks (again, IMO) do not impose undesirable architectural decisions on the system designer. [Idle thought: I suppose it might be useful to differentiate between "application frameworks" and "component frameworks." My comments above refer to application frameworks, which I'm not convinced exist yet in Labview.]

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

Is this restricted to AF actors specifically, or would our own actors also be first-class citizens?

I have experienced the exact same thing using LapDog over the past 10 years. There are very few (if any?) times when I have to have to write lengthy boiler-plate code that could be made more efficient with scripting.

I chose, "Other publicly available message-passing-style 'framework,'" though I could have also chosen "Your own or your company's internal framework or templates" or "Other (please post, this includes architecting each application from scratch)" since outside of a few templates I typically write each app more or less from scratch. (I will yank modules used in previous apps and modify as needed, but I don't typically bother making them into reuse packages.) Predictably, I use LapDog, and I'm glad you put "framework" in quotes as messaging libraries aren't frameworks. [Edit - BTW, thanks for posting this poll. I was going to ask the same question at my CLA presentation but had to cancel my trip at the last minute.]

FYI, I got a file permission error on Windows 10 when trying to set the file extensions I wanted the launcher to handle. It was easy enough to fix by manually giving myself write permission to C:\ProgramData\LabVIEW Tray Launcher\config.ini, but it is an issue I ran into. Also, do you have the source up on GitHub?

That's in line with what I remembered, but I didn't want to spread misinformation. (Age plays havoc on my memory.)

My apologies if I misrepresented what you said. Can you elaborate on why you recommend against using XControls?

I am under the impression XControls have more or less been relegated to the rusty nails bin. I know I've seen NI employees recommend against using them in presentations.

I'm in!

Nope. AFAIK the only way to set a class constant value is to write a VI setting the object's value, then copy the object with the desired values from an indicator and paste it onto the block diagram. I (as most developers I know) generally avoid using class constants on block diagrams and have adopted something more like what Dan suggests. Good ideas win out... For example, all my classes have a "Create <MyClass>" method that more or less acts like a constructor. The only time I ever drop a class constant on a block diagram is for typing operations (eg: upcasting or downcasting an object) or inside the class' Create method. You can use either parameters passed into the Create method or accessor methods to set the value of the object--it's a design decision. I quit using class constants to instantiate objects (other than in the Create method) primarily because it reduces flexibility. When I see an object wire on a block diagram, I want to know that object it going to work correctly. If a class has a reference-based construct--such as a queue--as a member, then an object instantiated from a class constant is not going to work until I call a method (eg: Init) that obtains the queue and stores it in private data.

I agree none of this is a trivial task and recompiling NI Linux RT to run on an x86 processor might be easier. I haven't looked at the source code (and have never recompiled Linux), do you have any idea how much code would need to be changed to support an x86 processor? My gut says more than I'd be comfortable with. FWIW, QEMU looks the most promising of the VMs I looked at.

I was thinking more along the lines of a direct ARM VM, not an ARM emulator running inside an x86 VM. There are a few out there... I haven't had a chance to try any of them yet.

No, I haven't tried to do this. I didn't know ARM-based VMs were available.

Wow... was it really four years ago that we talked about this? Time flies when you get old... I don't think I've used futures again since this thread** so I can't speak to the attitudes of the larger community, but my terminology preference is "future token" and "redeem." I do agree with Shaun though, it probably doesn't matter as long as you communicate it effectively and are consistent. [**My development focus over the last several years has shifted from pushing boundaries on actor-oriented and messaging systems to figuring out how to refactor, componentize, and deploy an NI-RT application across different target platforms.]

I've never thought of eliminating the object out for methods that do not change state... interesting idea. One side effect of doing that is you are also ensuring no child classes can ever change their state in the overriding method either. That may or may not be desirable in any given situation. Just out of curiosity AQ, how do you arrange your block diagram when making calls to multiple non-state-changing methods? Do you just run the class wire underneath the methods that don't return an object?

No, I didn't. To be honest it ended up on the ever-growing pile of partially finished things I hope to get to sometime.