Add direction arrows to the depiction of channel wires

[sfrinak1]

I have just had my first look at some sample VIs that were demonstrating the use of channel wires and I have seen channel wires going from left to right and also from right to left in the block diagram.  It was my understanding that LabVIEW best programing practice was to avoid backward wires.  The VI Analyzer actually tests for the number of occurrences of backward wires.  If the new programing best practice is going to allow backward channel wires, then to avoid confusion about the direction of data flow the channel wires should have a visual indication for the direction of data flow.  My suggestion would be a chevron design that indicated the direction of data flow, see attached file.

[admin edit 2016-09-15] Changed title of idea from 'Channel Wires' to something more descriptive.

[AristosQueue (NI)]

Channel wires flow in both directions simultaneously and do not have a direction. We explicitly looked at the idea of adding directional arrows and rejected it for that reason. Channels express a connection between parallel sections of code. They do not express a particular direction of flow. Even the Stream, which has only a single writer and single reader, allows for back propagation of abort signals.

The channel is a connection, not a directed flow, so direction arrows are misleading. This is consistent with other user feedback we have received.

This is a proposal we will continue to monitor for as channel use grows in the future and may revisit, but for now, I am going to close this idea as declined.

[Darren]

Declined for reasons listed here: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-direction-arrows-to-the-depiction-of-channel-wires...

[sfrinak1]

Let’s look at it another way, you have a Writer and a Reader and you have channel wires going from a Writer on the right of the block diagram to a Reader on the left.  You really should have some way of looking at the channel wire and  knowing immediately which end of the wire has the Writer.  Curved marks on the channel wire only indicate where the Writer is located in the block diagram.

[AristosQueue (NI)]

Like I said, we directly evaluated that theory and rejected it, even in the simple case of one reader/one writer. It is an idea that we may re-evaluate in the future after channels have been in the field for a while, but we are declining it for now.

[Zafer.Depe]

@AristosQueue (NI) wrote:

Channel wires flow in both directions simultaneously and do not have a direction. We explicitly looked at the idea of adding directional arrows and rejected it for that reason. Channels express a connection between parallel sections of code. They do not express a particular direction of flow. Even the Stream, which has only a single writer and single reader, allows for back propagation of abort signals.

The channel is a connection, not a directed flow, so direction arrows are misleading. This is consistent with other user feedback we have received.

This is a proposal we will continue to monitor for as channel use grows in the future and may revisit, but for now, I am going to close this idea as declined.

Although channel wires are against Labview data flow mechanism I don't understand why NI added such a feature. I know you are going to explain that it doesn't break data flow but at least visually it does. As you said above "channel wires don't have a direction". Isn't it against data flow mechanism? Channel wires work like "global variables or FGVs with wires" but look weird :). Lets think about beginners and their complex code. It is already difficult to read such a complex code. I think it will be more difficult with channel wires (even more with multi access on channel wires).

I see channel wires give really easy way to share data between points. But I am not sure if we had such a huge problem about data sharing. I wonder if experienced Labview users stopped using queues, notifiers or other synchronization methods.

[AristosQueue (NI)]

Zafer.Depe, you raise some good questions. Let me see if I can allay some of your concerns. They are similar to the concerns LV R&D team had when we started this project.

> Lets think about beginners and their complex code.

We've spent six years working on this feature, including putting it in front of new users. We did not add this feature without due diligence. 🙂 In all cases, from new user to experienced, we found the diagrams became significantly MORE readable than with existing solutions involving either refnums or variables.

> But I am not sure if we had such a huge problem about data sharing. 

By our team's evaluation, it is THE major problem most in needing of a significant advance affecting the largest number of users, with the possible exception of generic type propagation (the ability of a subVI written with, for example, integers, to autoadapt when wired with doubles or another numeric type). Generic type propagation would reduce the workload of many users, but fixing data handling prevents bugs that are extremely hard to detect and fix.

There are two problems with existing data sharing mechanisms (refnums and variables): existing solutions scale poorly and existing solutions are out-of-skill level for too many users. Even the basic queued-producer/consumer-loop is fraught with gotchas that hang up new and experienced users alike if they deviate even slightly from established patterns, gotchas that are sometimes hard to explain because of the race conditions involved.

As the average size of a LabVIEW application has increased, the problems with data maintenance in parallel modules have gotten consistently worse across the LV user base. The Actor Framework and its sibling frameworks (DQMH, Lapdog, JAMA, etc.) addressed this modularity beginning in 2010, but those frameworks address high dynamic use cases... they "feel" too heavy weight for the static cases. But they were (are) used because they were the best options available.

Channels attack the static module problem much more directly, and do so in a way that opens up a huge range of applications for lower-skill developers that were previously closed off to them. We've already observed that just in the problems attempted by users in the beta program.

> I think it will be more difficult with channel wires (even more with multi access on channel wires).

It might be more difficult for you -- I fully acknowledge that individual users experience features in different ways, and not all will want to adopt channel wires. From our research, however, we believe that the vast majority of users will find the code significantly easier to work on with channels than without. That's why we added them to the language! 🙂

This is a paradigm shift, no doubt, but it is small compared to the major shifts involved in the Event Structure, in LVOOP, or in the Actor Framework. Each of those technologies introduced far more shift in the look/feel of code, but each one is part of the standard toolbox of users today because it improved the maintenance of the code base.

> Isn't it against data flow mechanism? 

We do not believe so. Indeed, that is why they are referred to as "asynchronous dataflow" (not just by National Instruments but by other researchers in dataflow languages). Semantically, they provide the same fundamental safety for data that synchronous dataflow provides -- a process hands off data to another process rather than allowing multiple processes to keep their hands on a piece of data through a refnum or variable.

The wire does not have a synchronous direction because information is flowing bidirectionally, but the bits of data being handled in that bidirectional communication follow the rules of dataflow, atemporally.

>  I wonder if experienced Labview users stopped using queues, notifiers or other synchronization methods.

Here I shift to "I" instead of "we"... this is my personal expectation about the future of LV user patterns. There are various opinions across LV R&D about the future evolution.

I do not expect them to stop using those tools, but I do expect they will use those tools much less often. Using them directly for static situations will be replaced by channels. Using them directly for dynamic situations will be replaced by wrapping those in a framework like Actor Framework. There will always be specialized cases that need the raw access, but I don't expect to see them in use nearly so often as before LV 2016. I expect the migration to be gradual, with most applications having at least one channel in about five years. The Event structure took about 6 years, LVOOP took about 8, AF is still working its way through the user memespace after 4 years [from official release].

[Zafer.Depe]

@AristosQueue

Ok these are nice explanations about channel wires. I am not sure if I saw such an explanation before. Maybe I am a bit hasty about this new feature. I tested a little and found it weird 🙂 Here "Channel Wires vs. Actor Framework?" there is another topic about channel wires but doens't contain the information above. By the way I liked event registration mechanism but I think it is not available yet. I generally use AMC (with objects) or AF and get used to them a lot. I am sure some people will integrate this feature to the existing architectures or even more some new ones will be developed.

Thanks for the information.

Edited: "Channels attack the static module problem much more directly, and do so in a way that opens up a huge range of applications for lower-skill developers that were previously closed off to them. We've already observed that just in the problems attempted by users in the beta program." So far this is the most important thing for me. +1

---

[sfrinak1]

If channel wires can do everything that queues and notifiers can do, new users will not be learning or using queues and notifiers.  When these new users take over from the old programmers they will be scrapping years’ worth of good code because it will be actually be easier for them to just rewrite the code with channel wires.  Ten years from now there will be no queues and notifiers.

The other thing that I worry about is that when new programmers see channel wires going from left to right and right to left they will not see the necessity to use good programing practice and have all other wires just running form left to right.  Channel wires should have something that indicates that they are an exception to good programing practice.

[AristosQueue (NI)]

> If channel wires can do everything that queues and notifiers can do

They can't. There are high dynamic cases that cannot be expressed with channels.

>  Channel wires should have something that indicates that they are an exception to good programing practice.

We believe their unique appearance is sufficient. Time will tell.