Remove the stacked sequence structure from LabVIEW.

[PaulG.]

---

@Kevin_Price wrote:

---

@CoastalMaineBird wrote:

Why exactly are we supposed to be impressed with your bad code and your inability to see other options?

I listed several other options, and allowed how there might be more.

And I don't care whether you're impressed or not.

---

I've mostly skimmed through the thread with mild amusement.  It's been a long time since I added a SSS to one of my diagrams.  But, on reflection, sometimes my reasons were more about coding fundamentalism than rationality. 

I'll continue to think twice about any multi-frame sequence structures, but that's better than thinking no times and rejecting it only for dogmatic reasons.  My take away from the thread is to tell the SSS, "welcome back from banishment my little friend."

-Kevin P

---

Like I said: it's a holy war. It's quite amusing. I especially like the accusation that SSS has a "code-hiding problem". By that logic state machines and sub-vis would also have a "code-hiding problem." 

I rarely touch the SSS either. However, after this thread I may pull it out and start playing with it again.

[altenbach]

Back in the days, there was no FSS and screens were tiny. VIrutally all DAQ examples that shipped with LabVIEW were peppered with SSS because of that. This gave the new programmers the impression that the SSS is a central requirement for any DAQ.

I have exactly one application where the SSS serves a central purpose that would be more complicated if done in any other way (both frames have exactly the same inputs, but produce no output. There are no sequnce locals).

The time wasted on all these posts in this thread is way more than the time collectively lost by the LabVIEW community searching for the SSS in the 2014 palette. Dwelling on all these arguments simply does not make any sense. 😄 The SSS is still there! 

[rolfk]

I think the biggest reason for SSS to even exist was the fact that back in those days most LabVIEW nodes had little in terms of "artificial" data dependencies. Those GPIB nodes and many others had a device number input (but no output) and an numeric error code output. Proper programming would have meant to encompass any subsequent function with a case structure in case of errors but that seldom happened, causing monster programs that went into a series of timeouts if there was an error condition. If you wanted to make sure that a command got written to the device before attempting to read back the answer, you either had to use case structures based on the previous error code, something which was seldom done, and instead there was usually a 16 frame SSS, writing command 1 in the first frame, receiving the answer in the next, sending another command after and so on.

Nowadays almost all but the timing functions have error in and error out and often resource id in and out and don't require complicated programming nor SSS to have a proper programflow. 

---

But, on reflection, sometimes my reasons were more about coding fundamentalism than rationality.

---

A bit of fundamentalisme is not really bad. I prefer to tell every guy learning LabVIEW that SSS and global variables are bad and should be punished hard, and let them discover that there are spare legitimate reasons to use them anyhow once they have learned LabVIEW a bit, than letting them acquire bad habits. 

[CoastalMaineBird]

sometimes my reasons were more about coding fundamentalism than rationality. 

And that's the "dogma" I've seen over and over. I've asked for reasons, and gotten name calling and spurious crap, and "it is teh evil".

It's not a holy war from my POV.  Use it in your code, don't use it, it doesn't matter to me.  I just don't see a reason to take it away.

I'll continue to think twice about any multi-frame sequence structures,

The world will be a better place if we all think twice about all of it.

[CoastalMaineBird]

Proper programming would have meant to encompass any subsequent function with a case structure in case of errors but that seldom happened,

I remember when the ERROR IN - ERROR OUT chaining mechanism came to be, though I don't recall which LV version it was.

That went a long way toward simplifying such things - each VI included a "don't-do-this-if-previous-error" case, and you could just string 10 operations together and check once for errors.

[altenbach]

The presence of the SSS in the palette cause code like this! 😞

[CoastalMaineBird]

I'm sure you would agree that the presence of hammers leads to buildings like THIS.

Should we remove hammers from the toolbox?

[Hooovahh]

---

@CoastalMaineBird wrote:

Should we remove hammers from the toolbox?

---

The hammer is still in the toolbox, it is just hidden under the screwdrivers.

[ouadji]

a stacked sequence is not a hammer, but a toaster ... yes we should remove it from the toolbox !

[natasftw]

---

@CoastalMaineBird wrote:

sometimes my reasons were more about coding fundamentalism than rationality. 

And that's the "dogma" I've seen over and over. I've asked for reasons, and gotten name calling and spurious crap, and "it is teh evil".

---

You've offered the same.  It's rather hard to give any weight to your opinion when you consistently do exactly what you condemn.