-
Posts
1,982 -
Joined
-
Last visited
-
Days Won
183
Content Type
Profiles
Forums
Downloads
Gallery
Everything posted by drjdpowell
-
Poll on Architecture and Frameworks
drjdpowell replied to drjdpowell's topic in Application Design & Architecture
I've had a google and you're right, there are uses of "priority queue" for structures that are not analogous to common meaning of "queue". Wikipedia even labels a stack with priority as being a "priority queue". Personally I think this counterproductive when used with frameworks as only a subset of users will know the secret language. Surely we can use English words with their standard meanings. -
Poll on Architecture and Frameworks
drjdpowell replied to drjdpowell's topic in Application Design & Architecture
That's my point. You explaining that a theorectical elderly person might get priority means this is a priority queue and thus there was no other expectation of ordering, and that's why you cutting in front is ok...that ain't gonna go down well. -
Poll on Architecture and Frameworks
drjdpowell replied to drjdpowell's topic in Application Design & Architecture
That is a weird, though undeniably literal, interpretation of the words priority queue. You must get into a lot of arguements at the supermarket checkout. -
Poll on Architecture and Frameworks
drjdpowell replied to drjdpowell's topic in Application Design & Architecture
I'd expect there to be a very strong expectation that anything called a queue enforces ordering, as that is what the word queue means. -
Poll on Architecture and Frameworks
drjdpowell replied to drjdpowell's topic in Application Design & Architecture
Thought I'd show an example of "complexity" of a framework, according to my way of thinking, by comparing the priority messages of the NI Actor Framework and the DQMH: Looks the same from an API level (they even use similar icons). Let's look inside; here is the relevant code section for priority messages for the AF: Yikes! And here is the same for DQMH: Ah, much simpler. Now we can see which framework involves more complexity: the DQMH. Wait, what, you say? Isn't the obvious complexity of the AF implementation mean the AF involves more complexity? Well, no, because I, as User of a framework, care nothing about the implementation, I care about application I am building with these APIs. So let's consider the task of sending three high-priority messages, A then B then C. In what order will the three messages be received and acted on? With the Actor Framework the order will be A, then B, then C, ABC, always. With the DQMH we have: 1) if the receiver can execute them faster than they are sent, the order will be ABC 2) if the receiver is handling another message the order will be CBA (as we place on the front of the queue) 3) if the receiver is idle, but executing A takes time (allowing C to get before B), the order will be ACB 4) if busy but finishes after B is sent but before C is sent, the order is BCA 5) as (4) but B is finished executing before C sent, ther order is BAC Thus with the DQMH there are 5 possible orderings of execution, with the probability of the various orderings highly dependant on timing of not-directly-related bits of code (other messages being sent). At best, this is counter-intuitive and potentially confusing during debugging. At worst, one combination is a rare race condition that doesn't show up during testing and causes near-impossible-to-debug errors in deployed code. So that is an example of complexity, and it is certainly accidental, as the DQMH designers did not intend unpredictability of message-handling order when they used enque-in-front as message "priority". -
Poll on Architecture and Frameworks
drjdpowell replied to drjdpowell's topic in Application Design & Architecture
Exactly, but according to your definition it would be "accidental complexity". No, my original claim (that Daklu reacted against) was that a good framework reduces complexity. Working without a tried and tested...something (could just be a standard way of working that you are very expert in, but a "Framework" adds a library that supports that standard) leads to code that has extra complexity in it. Often that extra complexity is not obvious, but that's the worst kind of complexity. A particular bugbear of mine is NI templates like "QMH" and "Continuous Measurement and Logging" template/example that come with LabVIEW, which you might think are simple. I consider them very over-complicated. I've given more than one talk pointing out weaknesses in CM&L. -
Poll on Architecture and Frameworks
drjdpowell replied to drjdpowell's topic in Application Design & Architecture
What is a "framework" but a tried and tested template for design combined with a support library and hopefully some productivity tools and documentation? -
Poll on Architecture and Frameworks
drjdpowell replied to drjdpowell's topic in Application Design & Architecture
I think Daklu meant when your program is more complex than the problem it is solving. My problem with calling this "accidental" is that it sounds easy to avoid if you're careful, when really it is very hard to avoid lots of extra complexity. An example that comes to mind is shutdown/cleanup code. A good framework will handle cleanup simply and easily (this is an area I think Messenger Library is strong). -
Poll on Architecture and Frameworks
drjdpowell replied to drjdpowell's topic in Application Design & Architecture
Yes, I try to do that with "Messenger Library". Unfortunately, I find that if I stress that it is a library of messaging (with optional "actor" templates) that it gets dismissed as not to be considered when comparing "frameworks", but if I present the whole thing as a "framework", then people assume it is very restrictive. -
Poll on Architecture and Frameworks
drjdpowell replied to drjdpowell's topic in Application Design & Architecture
That "accidental complexity" is a killer. It's a big part of that exponential increase in complexity you showed on your graph a couple of posts ago. Helping to get that out of the way so you can address the true complexity of the actual problem is no small thing. -
Poll on Architecture and Frameworks
drjdpowell replied to drjdpowell's topic in Application Design & Architecture
How does MVA relate to your STREAM framework that you've blogged about? -
Here is a beta version, 1.11.0, with changes to TCP Messengers to support the various TCP options about ports and the like. Also adds a Keep-alive to detect half-open connections. Bitbucket Issues 26, 27, 33. I have not had time to do more than a basic test; it would be a help if someone could give it a try. Note that I've replaced some of the creation VIs for TCP Messengers in the pallette (originals should still work, but I wanted to change VI names). drjdpowell_lib_messenging-1_11.0_116.vip
-
JSONtext coverting Array of Enum
drjdpowell replied to Glen Rivard's topic in Code Repository (Certified)
That is Issue 34, which will be fixed in the next version. In the meantime, the fix is quite easy and described in Issue 34. -
Does your variant have a name? If it doesn't that's why it's name is "". Re attributes, you have to provide a variant containing default values of those attributes. This is because the JSON doesn't contain the LabVIEW type information (can't tell a string from a timestamp from an enum). I realize this is not the answer someone who uses variant attributes wants to here. Personally, though, I use sub-JSON instead of variant attributes, with cluster elements that are strings with the <JSON> tag in its name.
-
Issue 33
-
What number do I feed to "net address" to make it local host only? I wasn't aware of such a feature.
-
Worse, writing the image ref only triggers the need for a refresh of the control; the actual read of the data is asynchronous (like all LabVIEW indicators) and happens a short while later, possibly after the image has been changed.
-
Poll on Architecture and Frameworks
drjdpowell replied to drjdpowell's topic in Application Design & Architecture
A big part of the payoff of a good framework is making large complex applications simpler. But it's hard to see this when you're on the wrong side of the learning curve. -
Poll on Architecture and Frameworks
drjdpowell replied to drjdpowell's topic in Application Design & Architecture
Unfortunately, there is a significant learning curve for all frameworks, so it is hard to compare them. Here though is a GDevCon1 talk by Richard Thomas, where he discusses frameworks: Frameworks: An Executive Summary -
Poll on Architecture and Frameworks
drjdpowell replied to drjdpowell's topic in Application Design & Architecture
Ah, by-ref objects, GOOP, G#, and the like. That should have been a poll option. -
Poll on Architecture and Frameworks
drjdpowell replied to drjdpowell's topic in Application Design & Architecture
I remember a conversation, which I can't find now, where AQ mentioned that most messages will involve multiple bits of information, but I was surprised because I think it's natural for messages to usually only having a single piece of info. Often just a simple number, path, string. Even when the message contains a typedef cluster (or class) that typedef usually exists for reasons beyond the message. So I might have a "Data Set" object that passes through multiple actors for different types of processing, using a generic message rather than a number of type-specific messages. -
Poll on Architecture and Frameworks
drjdpowell replied to drjdpowell's topic in Application Design & Architecture
BTW, I was partly prompted to do this poll after seeing there is yet-another-framework on the Tools Network: WORKERS by Scarfe Controls. -
Poll on Architecture and Frameworks
drjdpowell replied to drjdpowell's topic in Application Design & Architecture
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". -
Poll on Architecture and Frameworks
drjdpowell replied to drjdpowell's topic in Application Design & Architecture
Ahh, your illustrating my point. DQMH is similar to SMO in having custom-type "plumbing", with new messages requiring changes in multiple places. AF also has its own busywork of multiple things to do for each message. Now, all this work is highly repetitive and thus scriptable. So you can value the strength of DQMH's scripting tools, because similar tools would be a help for SMO. But from the point of view of Messenger Library, which uses more generic messages, scripting is just a way of reducing one of the weak points of custom data-type messages: all the extra work to carry the new custom types through the communication code. Scripting Tools aren't a strength, they're the minimization of a disadvantage that is shared by DQMH, SMO and AF.