Poll on Architecture and Frameworks

[ShaunR]

3 minutes ago, drjdpowell said:

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.

 

Yes. A Priority Queue orders priorities.

[drjdpowell]

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.

[ShaunR]

13 minutes ago, drjdpowell said:

You must get into a lot of arguements at the supermarket checkout.

Well. My supermarket obviously isn't as isn't classy as yours. Flashing a Platinum Amex and then moving to the front would probably get you a bop on the nose.

Edited October 17, 2019 by ShaunR

[drjdpowell]

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.

[ShaunR]

3 minutes ago, drjdpowell said:

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.

Huh? I never said anything about an elderly person. Are you in the right thread?

[Aristos Queue]

A framework's artificial complexity is only from the things that the framework forces on your code, not the options that it enables if you choose to buy into it.

AF and DQMH without priority queuing are no more or less complex than AF and DQMH with priority queuing. The priority queuing only becomes a part of the complexity computations if "priority" were a required input and you had to send some messages at a non-normal priority. Because you can use both frameworks entirely without ever using priority, it isn't part of the computation. It is an option that you can choose to exercise in your code or not.

"If you buy it, you pay for it" features don't add complexity. "Comes with the territory" features add complexity.

The requirement to create a class per message: that is complexity of the AF. The ability to send high-priority messages is not.

 

[Aristos Queue]

2 hours ago, drjdpowell said:

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.

A priority queue DOES order priorities. You enqueue a pair of data items: a message and a priority. The queue sorts the pair by the priority. It just ALSO retains the secondary sort order of FIFO.

How the queue is implemented under-the-hood is anyone's guess, but ordering actual physical priorities is one possible implementation (and one that is used for an arbitrary priority heap).

[JKSH]

2 hours ago, ShaunR said:

There is a test for 1 that I have seen (can't remember off hand what it was called) but it was mainly for c/c++ and counted things like the number of if/else or entries in Case statements to arrive at a figure for "complexity"

Sounds like VI Analyzer

[drjdpowell]

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.

[ShaunR]

1 hour ago, Aristos Queue said:

It just ALSO retains the secondary sort order of FIFO.

Perhaps in the AF case. However it's also fairly common for the underlying implementation to be a stack (LIFO). That is effectively what the DQMH implementation is.

28 minutes ago, drjdpowell said:

Surely we can use English words with their standard meanings

Like "accidental"?  You understimate the power of a marketing department, my friend

 

Edited October 17, 2019 by ShaunR

[ShaunR]

1 hour ago, JKSH said:

Sounds like VI Analyzer

I don't think it does Cyclomatic Complexity Correct if I'm wrong because I rarely use it.

[Darren]

On 10/17/2019 at 7:56 PM, ShaunR said:

I don't think it does Cyclomatic Complexity Correct if I'm wrong because I rarely use it.

Moderator comment: Continued discussion here.

[Aristos Queue]

16 hours ago, ShaunR said:

Perhaps in the AF case. However it's also fairly common for the underlying implementation to be a stack (LIFO). That is effectively what the DQMH implementation is.

Like "accidental"?  You understimate the power of a marketing department, my friend

That would be a "stack", not a "queue." What the DQMH implements is a third thing: a "bug". 🙂

Note that it is a known, documented bug because the single message is good enough for DQMH purposes and not intended for more than one message.

Edited October 18, 2019 by Aristos Queue

[ShaunR]

1 hour ago, Aristos Queue said:

That would be a "stack", not a "queue." 

Potato, Potato

Quote

Array representation (unordered). Perhaps the simplest priority queue implementation is based on our code for pushdown stacks. The code for insert in the priority queue is the same as for push in the stack. To implement remove the maximum, we can add code like the inner loop of selection sort to exchange the maximum item with the item at the end and then delete that one, as we did with pop() for stacks. Program UnorderedArrayMaxPQ.java implements a priority queue using this approach.

Like i keep saying (and you agreed earlier) the Priority Queue is ordered PRIORITIES, not necessarily the elements (we disagree on this bit). The underlying implementation is irrelevant the name-it could even be a linked list.

Edited October 18, 2019 by ShaunR

[Daklu]

19 hours ago, Aristos Queue said:

A framework's artificial complexity is only from the things that the framework forces on your code, not the options that it enables if you choose to buy into it.

AF and DQMH without priority queuing are no more or less complex than AF and DQMH with priority queuing. 

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.

[Aristos Queue]

2 hours ago, ShaunR said:

Like i keep saying (and you agreed earlier) the Priority Queue is ordered PRIORITIES, not necessarily the elements

You're wrong.

[Aristos Queue]

1 hour ago, Daklu said:

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.

I'm not sure what the term is for the negativity introduced by options, but it is not (as I see it) the same as "complexity" being discussed elsewhere in this thread. The unused options do not add anything to the complexity as far as the user having to create more code or having more difficulty reading the code that they do create using the framework. Depending upon how the option is presented, it might not even add anything to the complexity of adopting the framework (there are plenty of optional terminals that we just gloss over on commonly used functions and never bother to even read about). To further complicate the issue, choosing to use an optional feature might actually decrease the complexity of the user's code written within the framework -- there are options that are available for specific tasks that avoid the user having to work out those tasks on their own.

While the learnability of a framework might be impacted by options, I don't think the complexity is changed by them. Does that make sense?

[MarkCG]

On 10/15/2019 at 9:58 AM, Aristos Queue said:

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'm interested in learning more about it-- can we see the presentation? I have never installed NXG but this sort of thing is what would sell me on it. My superficial impression has been that it's, at this point, LabVIEW with vector graphics.

[Daklu]

2 hours ago, Aristos Queue said:

The unused options do not add anything to the complexity as far as the user having to create more code or having more difficulty reading the code that they do create using the framework.

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.

2 hours ago, Aristos Queue said:

Depending upon how the option is presented, it might not even add anything to the complexity of adopting the framework (there are plenty of optional terminals that we just gloss over on commonly used functions and never bother to even read about).

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.

2 hours ago, Aristos Queue said:

While the learnability of a framework might be impacted by options, I don't think the complexity is changed by them. Does that make sense?

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?

[LogMAN]

As @Daklu mentioned, "complexity" is being used for various perspectives in this thread. Maybe this entire discussion should also be moved to another thread?

On 10/17/2019 at 11:32 PM, Aristos Queue said:

The requirement to create a class per message: that is complexity of the AF. The ability to send high-priority messages is not.

14 hours ago, Aristos Queue said:

I'm not sure what the term is for the negativity introduced by options, but it is not (as I see it) the same as "complexity" being discussed elsewhere in this thread.

Here is a definition for "complexity" I find helpful at times like this:

Quote

By the definition of complexity, its [(the software)] operating state space is very large and (all else being equal) it is more difficult to re-create an exact state in a large state space than to do so in a small state space.

The important part is "difficult to re-create". Now let me pick up the example from before:

By this definition of complexity, DQMH is indeed more complex than the Actor Framework because it produces many more potential outcomes (its operating state space is larger). The keyword in this example is "determinism":

• Priority messages in DQMH are nondeterministic (less deterministic is probably a better definition).
• Priority messages in AF are deterministic.

A subtle yet important difference. Of course, here we are looking at the complexity of the framework itself, not the complexity of the user's code.

On 10/17/2019 at 11:32 PM, Aristos Queue said:

A framework's artificial complexity is only from the things that the framework forces on your code, not the options that it enables if you choose to buy into it.

AF and DQMH without priority queuing are no more or less complex than AF and DQMH with priority queuing. The priority queuing only becomes a part of the complexity computations if "priority" were a required input and you had to send some messages at a non-normal priority. Because you can use both frameworks entirely without ever using priority, it isn't part of the computation. It is an option that you can choose to exercise in your code or not.

"If you buy it, you pay for it" features don't add complexity. "Comes with the territory" features add complexity.

When designing the architecture of a software, optional features like this should be taken into account. If determinism is a key requirement, AF is certainly a better choice than DQMH (not taking other key requirements into account).

Let's assume we went with DQMH. This decision can lead to higher costs in the future if determinism turns out to be important and priority messages are being used a lot. In this case there are multiple options:

• Keep using DQMH and work around the problem with a custom solution => see sunk-cost-fallacy.
• Switch to another framework like AF

You might think "that's never going to happen to me" => see Murphy's law

If options were truly optional they would be extensions, not part of the core framework. The fact that priority messages are part of the core framework is a strong indicator that it is not possible to create the same behavior with the API. Thus, it is not optional but an important feature of the framework.

14 hours ago, Aristos Queue said:

While the learnability of a framework might be impacted by options, I don't think the complexity is changed by them. Does that make sense?

As a user certainly, yes.

[ShaunR]

On 10/19/2019 at 10:04 AM, LogMAN said:

As @Daklu mentioned, "complexity" is being used for various perspectives in this thread. Maybe this entire discussion should also be moved to another thread?

Here is a definition for "complexity" I find helpful at times like this:

The important part is "difficult to re-create". Now let me pick up the example from before:

By this definition of complexity, DQMH is indeed more complex than the Actor Framework because it produces many more potential outcomes (its operating state space is larger). The keyword in this example is "determinism":

• Priority messages in DQMH are nondeterministic (less deterministic is probably a better definition).
• Priority messages in AF are deterministic.

A subtle yet important difference. Of course, here we are looking at the complexity of the framework itself, not the complexity of the user's code.

When designing the architecture of a software, optional features like this should be taken into account. If determinism is a key requirement, AF is certainly a better choice than DQMH (not taking other key requirements into account).

Let's assume we went with DQMH. This decision can lead to higher costs in the future if determinism turns out to be important and priority messages are being used a lot. In this case there are multiple options:

• Keep using DQMH and work around the problem with a custom solution => see sunk-cost-fallacy.
• Switch to another framework like AF

You might think "that's never going to happen to me" => see Murphy's law

If options were truly optional they would be extensions, not part of the core framework. The fact that priority messages are part of the core framework is a strong indicator that it is not possible to create the same behavior with the API. Thus, it is not optional but an important feature of the framework.

As a user certainly, yes.

I don't think it's that hard. You just have to use two words, one of which describes the domain. Learning complexity, system, complexity, code complexity, network complexity  et. al. They all adequately describe what's being talked about. I only had an issue with "accidental" complexity.

When using non-domain terminology (like "accidental", "inherent" etc) it needs more defintion in the statement, for example "the inherent complexity of the code". The inherent complexity of the system, etc. This is mainly a grammatical problem rather than semantic.

[LogMAN]

1 hour ago, ShaunR said:

You just have to use two words, one of which describes the domain. Learning complexity, system, complexity, code complexity, network complexity  et. al. They all adequately describe what's being talked about.

I wish it were that easy. Yes, they all adequately describe what's being talked about, but only when used in the same context. For example, what do you mean by "code complexity"?

• The amount of code in a single VI? => i.e. visual code complexity
• The way code is structured? => i.e. semantic code complexity (not sure if semantic is the right word for it. What I mean is code that is prone to interpretation by other programmers)
• The way code is executed?  => i.e. running time complexity
• The number of possible code paths? => i.e. cyclomatic complexity

It is my understanding that the first two points are about "readability", the third is "time complexity" and the last "code complexity".

1 hour ago, ShaunR said:

I only had an issue with "accidental" complexity.

When using non-domain terminology (like "accidental", "inherent" etc) it needs more defintion in the statement, for example "the inherent complexity of the code". The inherent complexity of the system, etc. This is mainly a grammatical problem rather than semantic.

Good point. "accidental complexity" confused me as well, but the more I thought about it, the more it made sense (good for me, I know). In my opinion "accidental complexity" is a good way to describe how architectures and frameworks can go sideways very easily if decisions inadvertently lead to additional complexity (code complexity, system complexity, whatever). I don't think it's an official term though.

Then again, English is my second language. I'll use that as an excuse 😋

 

[ShaunR]

1 hour ago, LogMAN said:

It is my understanding that the first two points are about "readability", the third is "time complexity" and the last "code complexity".

I think you answered your own question there and used the two term method that I described.

1 hour ago, LogMAN said:

In my opinion "accidental complexity" is a good way to describe how architectures and frameworks can go sideways very easily if decisions inadvertently lead to additional complexity (code complexity, system complexity, whatever).

This is exactly why I said:

On 10/16/2019 at 1:33 AM, ShaunR said:

What is "accidental complexity"? This sounds like an excuse given to management.