Is QMH obsolete? Am I wasteing my time?

[drjdpowell]

---

@Intaris wrote:
I'll give a different view on it.

Is walking obsolete now that we have bicycles?

Are bicycles obsolete because we have cars?

Are cars obsolete because we have planes?

Well, it depends on where you are, where you want to go and what you have available at the time.

But on topic: I personally don't view the QMH as obsolete at all. It's an important step in learning the basics so that you can possibly understand the reasons why other systems are set up differently. As this discussion shows, there is more than one way to fix the obvious problems with the QMH. Depends on where you want to go.

Having said that, I don't think I've ever used an NI template for actual code.

---

So you believe the NI-QMH design is a good one, like a decent bicycle or something.   That is the opposite of my view.  

[Intaris]

---

@drjdpowell wrote:

---

---

So you believe the NI-QMH design is a good one, like a decent bicycle or something.   That is the opposite of my view.  

---

No. That's not what I wrote.

I simply stated that the availability of a "better" (i.e. more advanced) version of something does not automatically make the previous thing obsolete. There are places for either. Is QMH (the general idea) obsolete because of "better" designs? No, I don't believe it is.

Stating whether QMH is a good bicycle or not is a completely different value judgement. I'm not going to give an opinion on that as I've never really used it and don't have an opinion. QMHs are valid when done properly. Whether NIs version fits that category, no idea.

[HorseBattery_Stapleguy]

---

@Taggart wrote:

---

@drjdpowell wrote: I see from Simple DQMH Dos and Don’ts  that experienced DQMH Users can use discipline to avoid the pitfalls of the NI-QMH design.   I would say about half of those Dos and Don'ts are ways to deal with the dangers of the two-loop system:

• Don’t perform extra processing or maintain state in the EHL
• Do make MHL actions atomic
• Don’t Enqueue inside of MHL
• Do make every MHL case a subVI
• Do maintain state only in MHL
• Do route everything through the MHL
• Don’t communicate directly between EHL and helper loops

Someone following these rules isn't going to get into trouble, but a new User is going to learn these only by painful trial and error.  Even for an experienced User, discipline is hard, and there will be a temptation to cheat of some of the rules. 

As the author of that, I tend to agree with you that beginners tend to learn those lessons the hard way. That's why I wrote them down for them to reference. And those are meant as guidelines, not necessarily hard rules. I break some of those on occasion, but very intentionally.

---

Pretty much this.

I don't think the architecture as a concept is obsolete however. In my case I do something very similar to crossrulz. I usually scope a loop/module in a library or class were each module has its own Queue AE, and I only expose communication with that module through a set of SubVIs that make up its API.

This is surprisingly useful for making updates to that module without affecting the rest of the code. And there's no wiring mess with queues visible in the diagram. (Which I think is a problem that can also appear when using channel wires thus the "rigidity")

And in the case of cyclical modules, instead of enqueueing to oneself I usually have the module check for incoming messages or continue performing its operation unless its meant to be atomic - non-interruptible for example. Which should help guarantee that messages get handled. (Provided everything else is right)

NI's template is another story though. There's plenty of possible race conditions. The templates should really have better documentation, more info on best-practices, do's and do nots.

One huge application I had to refactor in the past for example, used that template and abused the whole communication thing. Instead of scoping behavior, everything spilled onto all modules, where there were many loops communicating with one and another. So that was really hard to follow.

[FireFist-Redhawk]

---

@drjdpowell wrote:

---

@FireFist-Redhawk wrote:
If you tell novice developers "There's about 80 different ways to do this but this way is the best, so do it this way," but don't explain why it's easier, or less error prone, or more scalable, or just "fits" better for this specific use case, then IMO yeah you are setting them up for failure. 

---

That's the problem: the NI version of a QMH has been "taught" to generations of LabVIEW programmers as "the QMH", with no explanation of any reason why it is the way it is.  Since queued-message-handlers are extremely important, this very damaging.  Note that no DQMH expert was able to explain why the NI-QMH is the way it is or what advantages it might have; they just use it because it is the rote way taught by NI.  Groupthink.

---

After looking at the Help document for the QMH template for the first time, I'm not sure about this. The document is quite verbose and does have a "Use Cases" section and a "Modifying this Template" section. You get to it by going File, Create Project, select "More Information" under Queued Message Handler. No, I didn't read that entire thing line by line, but going from what I skimmed, it seems like decent documentation to me. Certainly a lot more than nothing.

As a general statement, I don't think NI should be responsible for putting out any sort of "Compare & Contrast" documentation comparing a bunch of different frameworks. Ugh suppose I'll list a couple reasons...

1. IMO there's no way to make that documentation truly objective. Every developer has their own take on when to use which framework. And as soon as that hypothetical documentation hypothetically comes out, there will be many opinions on what the writer missed and what they got "wrong".

2. It really doesn't make sense in the case of comparing QMH to DQMH. Why would it be NI's responsibility to compare their framework to a third party framework (no matter its popularity)?

3. At the end of the day, I feel like "Compare & Contrast" discussions should be done with actual, everyday users of the software.

[GovBob]

Just wanted to add this supplementary information to the discussion. 

[Taggart]

---

@FireFist-Redhawk wrote:
I'm gonna "steer" away from the car analogy (ha, ha ha). If you tell novice developers "There's about 80 different ways to do this but this way is the best, so do it this way," but don't explain why it's easier, or less error prone, or more scalable, or just "fits" better for this specific use case, then IMO yeah you are setting them up for failure.

---

You got it! That was exactly my point.

[Taggart]

---

@drjdpowell wrote:
  Note that no DQMH expert was able to explain why the NI-QMH is the way it is or what advantages it might have; they just use it because it is the rote way taught by NI.  Groupthink.

---

You should go watch Fab's Decisions Behind the Design videos where she clearly explains why DQMH is an improvement over the NI QMH. It's all there.

When you are in a hole, the way out is not to keep digging.

[drjdpowell]

---

@FireFist-Redhawk wrote:

---

---

That's the problem: the NI version of a QMH has been "taught" to generations of LabVIEW programmers as "the QMH", with no explanation of any reason why it is the way it is.  Since queued-message-handlers are extremely important, this very damaging.  Note that no DQMH expert was able to explain why the NI-QMH is the way it is or what advantages it might have; they just use it because it is the rote way taught by NI.  Groupthink.

---

After looking at the Help document for the QMH template for the first time, I'm not sure about this. The document is quite verbose and does have a "Use Cases" section and a "Modifying this Template" section. You get to it by going File, Create Project, select "More Information" under Queued Message Handler. No, I didn't read that entire thing line by line, but going from what I skimmed, it seems like decent documentation to me. Certainly a lot more than nothing.

---

Interestingly, I read that and didn't find anything much to criticize.  But that is because it only documents an Event loop and one or more Queue loops that do tasks like acquiring data.  It doesn't actually specify, as I have always seen everyone do and is part of Sam's "Dos and Don'ts", that one Queue loop should be the central "brains" of the app, with all State Data and all action routed through it.   It would be entirely possible to develop the template in a stronger direction, with the Event loop as the "brain" and all Queued loops as focused, simple "Helper loops".  One would have to add State Data to the Event Loop along with a User Event to receive messages.  Add some error handling, with all errors handled in the Event loop, and you have a simple architecture that isn't that bad.  My "DEV Template" in "Messenger Library" is basically a developed version of that.  

BUT, the described architecture is not complete enough to actually use, and the actual template generated makes further design choices, with the single Queue loop acting as brain (including the error handling).   This is the poor choice that is not documented, and I have never seen justification for.  It's the choice that makes this design so vulnerable to race conditions in the hands of the inexperienced, and causes the experienced to have to follow limiting rules to avoid problems.

[drjdpowell]

---

When you are in a hole, the way out is not to keep digging.

---

First stop digging, then get out of the hole.

[FireFist-Redhawk]

---

@drjdpowell wrote Interestingly, I read that and didn't find anything much to criticize.  But that is because it only documents an Event loop and one or more Queue loops that do tasks like acquiring data.  It doesn't actually specify, as I have always seen everyone do and is part of Sam's "Dos and Don'ts", that one Queue loop should be the central "brains" of the app, with all State Data and all action routed through it.   It would be entirely possible to develop the template in a stronger direction, with the Event loop as the "brain" and all Queued loops as focused, simple "Helper loops".  One would have to add State Data to the Event Loop along with a User Event to receive messages.  Add some error handling, with all errors handled in the Event loop, and you have a simple architecture that isn't that bad.  My "DEV Template" in "Messenger Library" is basically a developed version of that.  

I just don't agree on putting a list of Do's and Dont's in the documentation for a template meant for beginners, at that point it would basically be teaching how to code and that's what the LV Core classes are meant for. In terms of developing the template into something much stronger, if you were NI how much time/money would you want to spend doing that, when DQMH and JKI and AF are all out there and will almost always get chosen by experienced users over this new framework?

---

@drjdpowell wrote:

BUT, the described architecture is not complete enough to actually use, and the actual template generated makes further design choices, with the single Queue loop acting as brain (including the error handling).   This is the poor choice that is not documented, and I have never seen justification for.  It's the choice that makes this design so vulnerable to race conditions in the hands of the inexperienced, and causes the experienced to have to follow limiting rules to avoid problems.

---

I think the decision behind those things is that in the vast majority of cases of this template being used, extra loops won't be added. In which case one doesn't need to worry about how to send errors from 5 loops into one. And no frameworks are immune to race conditions. If an inexperienced user is starting to get into LV, race conditions are just something they're gonna have to learn about sooner or later. I would almost argue that all frameworks are equally susceptible to race conditions if the developer is someone who has no idea what race conditions are.

At this point it probably seems like I'm a big fan of QMH but that's not the case. Like many others, I've made my own framework that's way better. I just feel like it's getting a tonnnnn of hate, and a not-insignificant portion of that hate is unjustified IMO. If all you need is two loops to achieve what you want, then it's really not that bad. Once you start adding more and more loops, the framework's cracks really start showing in terms of documentation and error handling. And at that point, maybe the developer has the idea to abandon the "axe" template and redesign their VI with more of a "chainsaw" template.