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?