Remove the stacked sequence structure from LabVIEW.

[BaptisteC]

Hi coastalMaineBird,

Obviously I do agree that you can't ban something just because some dont/cant use it properly but the différence between cars and SSS is that there is no reasonable way to get rid of every car in the world, we need those.

It is not the case of SSS, we can do without

Sure they can be used properly (like cars) but they can lead to really bad programmation habits.

If they were a safer way to replace cars all over the world which would allow us to avoid every accident I would want the car banned even tho I like driving those.

I didn't mean to say using SSS is bad by itself, I just don't see any actual advantage compared to other ways and I know that as long as they exist some people are gonna use them in a wrong way (and some develloppers are gonna be call to the rescue and cry).

Since we both agree that a devellopper licence would be a bad idea, why not try and ban the tools in your toolbox which can be misused and can be replaced by other tools?

Baptiste

 

[PaulG.]

---

@CoastalMaineBird wrote:

... I don't see what is "horrible" about sequence locals ... 

---

Was going to leave this discussion alone but I need to chime in: the sequence local is probably the worst feature of LV. It's the antithesis of data flow. IMO it's the only thing that ruins the sequence structures. But it's enough. Had SSs been given shift register capability and NOT sequence locals we probably would not be having these discussions - at all - ever.

[ouadji]

@PaulG :

the sequence local is probably the worst feature of LV. It's the antithesis of data flow. IMO it's the only thing that ruins the sequence structures.

Had SSs been given shift register capability and NOT sequence locals we probably would not be having these discussions - at all - ever.

     kudo.

[rolfk]

---

@Stel wrote:

This is all good for new projects but when addressing older code it is not much to expect full backward compatibility with LV.  A lack of backward compatibility has happened a number of times in the past, whereby moving from one version of the platform to the next turns into a costly time consuming excercise.  I am not against moving the LV product forward, on the contrary I think there is a lot more to do on that front, however you need to consider legacy aspects of a product that has been around for so long.  So if you don't like stacked sequences don't use them ... perhaps just close your eyes.  As they say, if it ain't broke don't mend it!

---

Nobody is going to remove the SSS from LabVIEW itself. NI has traditionally always gone to a lot of effort to make sure code from earlier versions loads and executes seemlessly in a new version. The worst they will ever do is to remove the SSS completely from the palettes and that is something I would fully support. The SSS is pretty useless, promotes bad programming practices and the sequence locals are a complete pitta in every sense. Basically the sequence locals are even almost superflous since if there is data dependency anyhow (otherwise the need for sequence locals would be not there) then the sequence structure is actually superflous at that point.

My rule of thumb is basically:

- SSS for anything but quick throwaway code is BAAAAD

- SSS with sequence locals is TERRIBLE

This is my opinion, based on 23 years of LabVIEW programming experience and debugging and improving many LabVIEW programs that were build around the assumption that SSS are the only way to force LabVIEW to do proper execution orderering of its primitives.

[Yamaeda]

But ... but ... SSS' are the best way to get the code to fit the screen! 

😉

/Y

[rolfk]

---

@Yamaeda wrote:

But ... but ... SSS' are the best way to get the code to fit the screen! 

😉

/Y

---

And duct type is the best way to prevent a rusty car from falling apart! 

[PatrickR]

I find SS to be a fairly elegant way time a subVI.   Read time the first frame, all the code in the second, read time again in last frame and subtract from first frame time.    Yes, you could also use a flat sequence, but I find the SS to be less clutter.

Another problem I have encountered is with Control Referneces in LabVIEW.   Trying to access/manipulate front panel controls from a subVI is a bit painful.  So in an app I just developed I basically had the decision of attempting to bundle every single control I had on the front panel (and there were dozens) into a typedef'd cluster, then passing that cluster to the suvVIs, or just keep all the GUI manipulating code in main VI and using SS when I ran out of screen real estate   I find this easier from an programmer perspective. 

If you make small, well contrained programs, yes its fairly easy to avoid SS and criticize those who use it.     But if you have complex programs that require lots of GUI maniupatlion, SS is not so easy to avoid. 

If I was rewriting LabVIEW I would base it more around an OO methodology.   The OO that LabVIEW has no feels clunky and bolted on, disconnected from real use (the API barely uses it, why should the user?)     Good OO languages (Java, Python) are built like that fron the ground up.   When OO gets bolted on, you end up with monstrosities like C++   The front panel VI should be an object whose controls are named properites, not just thrown in an array like they are now.   That would solve the problem of having to explicity bundle control refs into a cluster, you could just pass the ref to the front panel, and you would get all the controls as named properties of the front panel.

[billko]

---

@PatrickR wrote:

I find SS to be a fairly elegant way time a subVI.   Read time the first frame, all the code in the second, read time again in last frame and subtract from first frame time.    Yes, you could also use a flat sequence, but I find the SS to be less clutter.

Another problem I have encountered is with Control Referneces in LabVIEW.   Trying to access/manipulate front panel controls from a subVI is a bit painful.  So in an app I just developed I basically had the decision of attempting to bundle every single control I had on the front panel (and there were dozens) into a typedef'd cluster, then passing that cluster to the suvVIs, or just keep all the GUI manipulating code in main VI and using SS when I ran out of screen real estate   I find this easier from an programmer perspective. 

If you make small, well contrained programs, yes its fairly easy to avoid SS and criticize those who use it.     But if you have complex programs that require lots of GUI maniupatlion, SS is not so easy to avoid. 

If I was rewriting LabVIEW I would base it more around an OO methodology.   The OO that LabVIEW has no feels clunky and bolted on, disconnected from real use (the API barely uses it, why should the user?)     Good OO languages (Java, Python) are built like that fron the ground up.   When OO gets bolted on, you end up with monstrosities like C++   The front panel VI should be an object whose controls are named properites, not just thrown in an array like they are now.   That would solve the problem of having to explicity bundle control refs into a cluster, you could just pass the ref to the front panel, and you would get all the controls as named properties of the front panel.

---

You could just bundle the references of the front panel controls.  If you make constants from the references, you can put them in a cluster and typedef it so that every time you make a new control you could add to the cluster and all your clusters would update.

[edit] Or is that what you meant but you just forgot to say "reference"?[/edit]

[BowenM]

There is one thing all you "good" LV programmers are forgetting when you say you want the SSS removed.  And it is the reason it won't ever be removed (in my opinion).

It is abused by newbies. And from NI's perspective, this is a GOOD THING.  Why?  Because that means it is a feature that newbies find useful. It allows them to think and code in a manner that is procedural rather than data flow. 

One of LV's major selling points is that it can be picked up and quickly used by people who are relatively (if not completely) new to programming.  Because of this reason you see it popping in applications like university electronics labs. It allows instructors to focus on the electronics, and not on the programming.

Yes, for those of you who have been coding for years, they are an abomination. But sadly, you are the smaller percentile of NI's customers.

[BowenM]

Editing the double post for a little bit of "clarity"

All the reasons you hate the SSS are reasons that NI wants to keep them 🙂