LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
parthabe

Rename the "Enqueue Element At Opposite End" Queue primitive as "Enqueue Element At The Front"

Status: New

 

The title says it!

 

It is often confusing "Which is the opposite end in a queue?/What does opposite end mean?", esp for new user of LabVIEW. Smiley Frustrated

 

Seems here, even the author of the LV Queue primitives was not able to recollect its name correctly. Smiley Wink

 

Also, please see below from the LV Help. Smiley Happy

 

 

Enqueue Element At Opposite End.jpg

- Partha ( CLD until Oct 2024 🙂 )
17 Comments
GuenterMueller
Active Participant
I like your idea and the justification you have given. However, as long as its name is "Enqueue Element At Opposite End" no one needs to learn the queue implementation details and can easily select the desired implementation by name when adding an element to a queue.
altenbach
Knight of NI

 I fully agree that the language should be simplified!

 

(Ideally, we only should have one enqueue function but with additional inputs for "lossy T'|F" and "Normal|High priority" where high means at the front)

altenbach
Knight of NI

The term "... at opposite end" alway reminds me of this old story. 😄

parthabe
Trusted Enthusiast

altenbach wrote: "... and "Normal|High priority" where high means at the front)"

 

 

My suggestion would be "Queue (F)/Stack (T)", where Stack means insert (add) element at the front (today's Eneuque at the Opposite End).

- Partha ( CLD until Oct 2024 🙂 )
Intaris
Proven Zealot

I don't like the Stack notation, mainly because I did not immediately understand what was meant by that.

 

I was thinking that everyone knows that the "front" of a queue is and the "back* of a queue so that would seem to make sense.  I don't know how universal that is in all cultures though.

AristosQueue (NI)
NI Employee (retired)

TL;DR is in boldface.

 

> I was thinking that everyone knows that the "front" of a queue is and the "back* of a queue so that would seem to make sense.

 

That terminology was not widely recognized among LV users when the queue prims were named. I did not have anywhere near the contact with the user community when I made the queue primitives that I do today, so I was largely guided by senior programmers when choosing the names. Having said that, over the years, I find that if I talk about "the front of the queue", I often get blank looks from large swaths of USA audiences and I have to explain which end is which. It seems to be more intuitive in Europe. I don't konw why ... perhaps because over there, students are taught to queue whereas in the USA they are taught to line up. But for whatever reason, "front" isn't a good descriptor, IMO. The text in the Context Help about "front" was to connect with those with the formal data structures background (or who had visited Britain) who might recognize that term. "Opposite end" just means "not the usual end" and it doesn't require the user to model the queue in their head in a particular way -- some people see the front as on the receiver side, some see it as on the sender side.

 

I'm open to the rename suggestions, but I would push back on turning the separate functions into a parameter on a single function because of the reasons below.

 

Using separate primitives was very deliberate instead of a Boolean option. There are nearly zero situations where you conditionally enqueue at the back end or at the front end EXCEPT for trying to use the front end as a priority queue -- but using the Enqueue At Opposite End to create a priority queue is a Generally Bad Idea because it only works for a single message -- Stop. (Not a single class of message, but a single message.) If you try to use it for anything else, you get race conditions, and that's not generaly recognized by code authors (I see that error all the time). The separation into separate primitiives was meant to make it quite clear that these are separate operations meant to be used separately, not an option that flickers back and forth at run time. It is a division that I believe has kept the number of mistakes made with the prims down from what they would be otherwise.

 

The term "stack" reintroduces compuer science specific concepts. Yes, this is straightforward to explain, and after explaining it then the term serves as a useful shorthand for the concept, but I don't think LV's core user base has moved that far from its origins. It's gotten larger and reaches deeper into the programming base, but it's still not got its majority in that camp.

 

All of that is just to give you background on why the nodes are the way they are today. It is not meant as a rejection of the suggestion for changes. The Idea Exchange is meant to encourage discussion of when things in LV should change, so keep the conversation and brainstorm coming, please.

Intaris
Proven Zealot

Well I guess AQ just answered my " I don't know how universal that is in all cultures though" question.... Smiley Very Happy

GuenterMueller
Active Participant
Oh no: AQ also gave as some insight why the name is not "Enqueue Element At The Front".
Darin.K
Trusted Enthusiast

I don't care what you call it, I want "Dequeue at Opposite End".  (Actually I'd prefer four operations named Enqueue/Dequeue/Push/Pop).  The naming issue is much, much less annoying to me than the absence of a true deque implementation.

parthabe
Trusted Enthusiast

Then, log a separate idea!

- Partha ( CLD until Oct 2024 🙂 )