Tunnel Mode First Value

[tshurtz]

I sometimes want the first result from a tunnel on a loop. I end up using a auto indexing tunnel and then just indexing off the 0th value. Not a huge deal, unless the data type is something huge or I am doing tons of iterations and then I am just wasting memory. I guess I could put in a last value and make it conditional on i=0 but that is extra mess. You would probably want to make the tunnel icon look different so its obvious whats happening. maybe something like

[AristosQueue (NI)]

> I guess I could put in a last value and make it conditional

> on i=0 but that is extra mess.

That is what I would advocate you do. I push back strongly on ideas like this one: ideas that introduce highly specialized notation on the diagram for rare situations. And this one is very rare. Not non-existent, but very rare. Strange notation on diagrams make it harder for others to read the code and lead to a searching documentation to understand what a diagram is doing. That works against the goals of graphical programming. A simple =0 node off of the [i] terminal is easy to read and leverages existing notation.

We will leave this idea open in case it garners lots of kudos such that we reconsider it, but even with high kudos, it's the kind of feature that would have a downside for all the people not asking for it, which would make R&D hesitate.

[tshurtz]

Is the down side for everyone else that there would be one more entry in the right click pop-up menu? 

Thats not that big of a deal in my opinion and I would hardly say that the conditional last value is clear. It makes sense when you think about it for a bit but the last value where i=0 is not super straight forward. I agree it isn't the most common need but I would rather have options for things that I rarely use but are elegant when I do than fewer options.

Out of curiosity the compare to 0 every loop is probably very low resource cost, but is the compiler smart enough to throw it out completely?

[wiebe@CARYA]

>Out of curiosity the compare to 0 every loop is probably very low resource cost, but is the compiler smart enough to throw it out completely?

If 'first value' was an option, would it be thrown out completely?

There is code required to do it (in both cases). doing it manually (in "G" code) might be just as efficient as the 'first value' idea.

[wiebe@CARYA]

If 'first value' would be there, I'd want a 'conditional first value' to be possible. The first time the condition is true, the value is written. Second time the condition is true, it keeps the 1st value...

A workaround for a 'conditional first value' would be harder. I have needs for this every now and then. Often,not always, you can use the stop condition to stop the loop and return the last value, effectively returning the first value. A workaround is a lot of work (relatively).

[AristosQueue (NI)]

> Is the down side for everyone else that there would be one

> more entry in the right click pop-up menu? 

No. The downside is they are trying to read your code (or anyone else's code that uses this feature) and see a [o] and have to go figure out what that means. There is lots of specialized syntax that we can add to diagrams for niche cases. Put in enough of that and we would lose the ability to generally read each others' code -- this is something that happens in other programming languages that become profligate with specialized syntax. There's a threshold -- some computation of how hard is it to write and how often do I have to write it and how weird is the existing syntax -- where it makes sense to add new syntax. That isn't a nice linear function, not something I can tell you how to measure. But after 20 years of doing this and evaluating user reaction to different diagram changes, my sense is that this is below the threshold.

[tshurtz]

>No. The downside is they are trying to read your code

I understand your reasoning but I respectfully disagree. At some point we were all new and we had to learn the syntax. Sure if there dozens of different things in there it would be tough to keep track of. But with hover context help its not that bad. I would much rather a have a simple looking well documented way of doing it than try to understand someone's logic. Especially because they might chose a different way to do it (with an array, with a shift register, with conditional on i=0). It gets really messy if i is being used elsewhere in the loop and you have to cross other wires to get it over to where you need it. 

Maybe I am not a typical user but when I see a new feature in someone's code that was not readily available in the pallet or there but uncommonly used I mentally say whats this, look it up in the help menu and then think "I have always wanted a better way of doing this. This is awsome" and I log it away for later. 

I would agree that changing things users are used to without need is a pain and I hate when software companies do it. Like rearanging the menu and calling it a new version. But adding features without breaking old ones has only ever pleasantly surprised me. I have only been using LabVIEW heavily for 5 years but each new version brings new features I love and want to use. And the more the better in my opinion. I would hate the programming language to stagnate because adding a feature might be new (and slightly confusing) to someone who is used to the old way of doing things. This isn't me arguing for this specific feature, rather to make the program feature rich in general.

[AristosQueue (NI)]

> I understand your reasoning but I respectfully disagree. 

I know. 🙂 Everyone disagrees for their pet piece of syntax. I've got a few that I think would be great additions that my team has shot down over the years. It is my team's job to look at the utility to the user base overall, the ROI for developing the new syntax, and curtailing the overall complexity of G. It's a balancing act.

> Maybe I am not a typical user but when I see a new feature

> in someone's code that was not readily available in the pallet

There is a different standard between a new node and a new language element. One is a bit of functionality that is called whenever the wire values reach that node. The other is an entirely different way of interpreting what happens when values reach a node. You could argue that because we've already introduced terminals with side-effects that this is just a new node, and that's a reasonable argument. But there is not much space in that area to provide a meaningful glyph... R&D has hesitated on a couple other similar ideas for autoindexing augmentation for similar concerns.

The idea remains open for kudos. We have the Idea Exchange to help correct R&D when we're wrong in our sense about the utility of proposed features. We'll see how it develops.

[wiebe@CARYA]

If you can't use the stop condition to get the fist value (by actually getting the last value and stopping), the alternative is hard to read.

So if readability is the issue (and I agree it is an issue), what is harder to read? This new proposed option, or an alternative?

I go for a +1... But only if 'conditional' also works.

BTW. This all sounds familiar, I think we had this discussion before? Not on readability vs features, but on the first value idea. Can't find it though.