Remove the stacked sequence structure from LabVIEW.

[Blokk]

If I need more space to write code I need to call a Vi with the same single screen space restriction.  Without Stacked Sequences to write a reasonable amount of code will require me to make a DLL call etc to a real programming language.

I just do not get why many people think they need to use Stacked Sequence Structures in their code. You can easily build up a while loop with a state machine. If you use a state machine you have as many cases as you wish, and also you have to the chance to abort or interact with the ongoing sequence! You do not have these options using SSSs... The above statements are just not true.

[ff377]

I appreciate the issues that Stacked Sequence can create. Even though it is hidden, I am glad that at least for now we can still use it. Still I want to make the point before it is removed completely that some people may still have a need for this tool.

“You can easily build up a while loop with a state machine. If you use a state machine you have as many cases as you wish, and also you have to the chance to abort or interact with the ongoing sequence! “

Once in a single state someone may still have a lot of code to write that is limited by the screen size. This code can be put into another VI with still the same screen size restrictions. I believe in a well structured and readable programs. Still programming should be limited by your imagination, not the size of your screen. Clearly people have strong opinions in this subject and all I ask is Stacked Sequence structure remain an option.

[DrStel]

I just think there is no reason why a tool should be removed from the LabView pallette to be kept in the library in any case - just purile inconvenience.

[Hooovahh]

---

@ff377 wrote:

This makes Labview a toy. I have a picture logic program that now limits the amount of code I can write in a case statement etc to the size of my screen. 

---

I think software that is toy like, is code that isn't planned and architected in a way that makes it more Scalable, Reusable, Extensible, Modular, etc.  Using sequence structures breaks all of those rules.  State machines are the way to go in many simple situations like the ones you are doing.  They are better than sequence structures in every way.  Learn to use them and you will love programming in LabVIEW more, the developers using your code will love it more, and your users of your software will love it more because it can be more responsive.

---

@DrStel wrote:

I just think there is no reason why a tool should be removed from the LabView pallette to be kept in the library in any case - just purile inconvenience.

---

There are reasons tools should be removed, newer advancements make them obsolete, and they encourage bad programming concepts.  This may seem like an inconvenience to you, but opening someone elses code that didn't design it and just threw it together in as a mess, is a major inconvenience for a new developer.  Removing this from the palette doesn't make all bad code good, but it is a step in the right direction.

NI is very good about keeping legacy compatibility.  LabVIEW Scripting wasn't official in LabVIEW 7.x (13 or so years ago), but I don't know of a single scripting function that was written then that isn't supported today.  There may be some I just haven't found one yet.  My point is NI is very good about not breaking old code especially relating to functions that once were on the palette.  If they did they would have it in the release notes, and in the up conversion I'd suspect there would be some kind of warning or error.

[Blokk]

"Once in a single state someone may still have a lot of code to write that is limited by the screen size."

This is not an argument. First of all, use subVIs. Second, if the BD size of the state "A" is not enough, then create multiple A states...

[crossrulz]

---

@Blokk wrote:
Second, if the BD size of the state "A" is not enough, then create multiple A states...

---

To phrase this argument a little differently: If state A is too large, then you are likely not making your states modular enough.  Therefore you should break up state A into multiple states.

And nobody said there is a limit based on the screen size.  It is just desirable to keep the block diagram to a single screen, or scroll in a single direction if necessary.

[NIquist]

---

@crossrulz wrote:

And nobody said there is a limit based on the screen size.  It is just desirable to keep the block diagram to a single screen, or scroll in a single direction if necessary.

---

I was confused on his mention of that too.  I don't know what the actual limit is but I can still create humongous empty loops in LV2014.  Is it changed in 2015? 

[Yamaeda]

---

@ff377 wrote:

Once in a single state someone may still have a lot of code to write that is limited by the screen size.

---

A VI can be a lot bigger than the screen, 16000 x 16000 last i checked. If that's too small for you, you have problems.

The Styleguide suggests keeping VI's to one screen, which is a way of avoiding the anti-pattern god-VI's (or god-functions/god-objects in other languages). It's a suggestion, but if e.g. making a VI with .net nodes it can quickly grow beyond a screen width. If that's the case, fine. Sometimes it's hard to avoid, but it shouldn't be common.

/Y

[Ben]

---

@DrStel wrote:

You need to create a FLAT SEQUENCE STRUCTURE and then right-click on this and select the REPLACE WITH STACKED SEQUENCE item.  Go figure what the logic behind NI's thinking is ... but it doesn't make sense.  All it does is annoy, as it has managed to replace a single step process with a two step process.

---

Now what does this remind me of?

Ben

[billko]

These latest arguments for the stacked sequence reminds me of the old "goto" battles.  Except that maybe the people arguing for "goto" had a more valid argument than the arguments for using a stacked sequence.

(Even with my limited knowledge of text-based programming, I always thought that "goto" was a bit of a cop-out, reserved for when you couldn't figure out how to do it the "right" way.)