Remove the stacked sequence structure from LabVIEW.

[natasftw]

With respect to clarity, I doubt anyone here actually expects it would be removed or believes the removal would be an easy task.

Why would NI think the abuse is a good thing?  From NI's perspective, I'd imagine they'd want people to have a pleasant experience.  If something is easily abused and this causes problems, this translates into more headaches and frustrations for the beginner programmer.  An upset customer is likely to not only avoid NI, when possible, they are also likely to spread bad word of mouth advertising.  You're manufacturing an easieness of use that simply doesn't exist.  The problem isn't that it's easy to use the SSS correctly.  The problem is that it's very difficult.  This is the exact opposite of your claim.

If the structure leads to messy debugging situations, this forces beginners to focus on the programming rather than the electronics.  This, again, is the opposite of your claim.

In my univeristy, we never saw either of the sequence structures.  There simply isn't a need for them in those settings.

[BowenM]

"Abuse" is a matter of perspective. To all of the "good" coders, it is abuse. To the newbie sitting down for the first time, they are a great way to organize your code, ensure data flow, etc. My argument was that they are used so frequently because they are attractive to the new programmer.

[billko]

---

@BowenM wrote:

"Abuse" is a matter of perspective. To all of the "good" coders, it is abuse. To the newbie sitting down for the first time, they are a great way to organize your code, ensure data flow, etc. My argument was that they are used so frequently because they are attractive to the new programmer.

---

I would never tell a newbie to C rogramming to put all the stuff in one function because it's easier than creating a function for each... well... function.

Besides, you're NOT ensuring dataflow.  Sequencing and dataflow have some things in common, but they aren't the same.

[crossrulz]

---

PatrickR wrote:

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. 

---

That tells me you have way too much coupling happening between your GUI and your code.  Each subVI should do 1 very specific thing and it brings in and puts out only what is related to the function.  I find User Events are a much better way to send updates to your GUI.  Leave the GUI to your GUI loop.  Leave the actual processing of data to your data processing loops.

[natasftw]

Using it poorly isn't something that is relative to experience.  If you're using it poorly, this is true regardless of whether you know you are or not.

As an example, it doesn't make sense to build adds nested in a for loop to handle multiplication.  It works.  It might be something one could think of easily.  But, there's already a multiply function.  If one uses the for loop from inexperience, that doesn't mean their code isn't bad. 

Similarly, using the SSS because it's "attractive" rather than using something more fit to the task is abuse independent of the programmer's skill level.  They may not realize they're abusing it.  But, they certainly are.  You cannot rationalize their usage makes sense because they don't know any better.  You're also ignoring the greater problem that arises when they are frustrated trying to troubleshoot the mess of code they put together due to inexperience.  None of this matches with what you suggest NI sees when they see the SSS.

[BowenM]

---

@billko wrote:

---

I would never tell a newbie to C rogramming to put all the stuff in one function because it's easier than creating a function for each... well... function.

Besides, you're NOT ensuring dataflow.  Sequencing and dataflow have some things in common, but they aren't the same.

---

Of course you wouldn't.  To a "C" coder, each frame is a function. It does one specific purpouse with each  sequence local is an input/output to that function. It is procedural code.

[natasftw]

Now you're getting away from the original point.

A c-coder is not someone new to programming.  As such, they aren't the class of people new to programming that he's suggesting NI seeks to attract by using this structure.

[PatrickR]

---

@crossrulz wrote:

---

PatrickR wrote:

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. 

---

That tells me you have way too much coupling happening between your GUI and your code.  Each subVI should do 1 very specific thing and it brings in and puts out only what is related to the function.  I find User Events are a much better way to send updates to your GUI.  Leave the GUI to your GUI loop.  Leave the actual processing of data to your data processing loops.

---

I do use user events quite a bit.   On my main VIs my architecthrue goes Initialization -> While loop containing an event handler -> Program cleanup (if any)

I try as much as possilbe to seperate the GUI stuff from data collection.  However, sometimes there is tight coupling and the problem cannot be broken down into subVIs without also dealing with the UI.

Consider this simple problem:   A data collection/display loop, with a "stop" button.   You can't turn this into a subVI without passing your display control refs to the sub VI, because you can't update anything from the main VI until the subVI completes.  Which it won't, until the data collection is complete, but say you have several frames and want to update each frame.,   Even without the data display (say you're just saving it to disk or something), if you have a "stop" button, you would also need to pass a control ref to the subVI so the data collection loop knows when to quit.  

Yes, you could put most o fthis (at least the data collection loo)  of this at the top level.   Thats exactly what I did.    And as the program becomes more complex, with maybe different ways of acquiring data (requiring different loops) , you start using a alot of screen real esate ..... which leads to either having to re-architech with a subVIs and passing control refs, or using the SSS.   The second option (SSS) is simpler from the programmer's perspective, but of course not for anyone reading the program .

Like I said, if I was able to simple pass just the control ref of my top-level VI, and get all of its controls as named properties, this would solve the problem and make the top-level VI much simpler, without having to bundle the oodles of control refs my program uses or resorting to an SSS.   This is possible/typical for  good OO language such as Java.  But in LabVIEW the only thing I have access in a top-level VI ref to is a bunch of controls thrown haphazardly into an array, with no way to say which control it actually is (i.e, they aren't named)

[natasftw]

---

@PatrickR wrote:

Yes, you could put most o fthis (at least the data collection loo)  of this at the top level.   Thats exactly what I did.    And as the program becomes more complex, with maybe different ways of acquiring data (requiring different loops) , you start using a alot of screen real esate ..... which leads to either having to re-architech with a subVIs and passing control refs, or using the SSS.   The second option (SSS) is simpler from the programmer's perspective, but of course not for anyone reading the program .

---

Here's your primary problem.  You box yourself into two bad options and suggest one is the lesser of two evils.

http://www.ni.com/white-paper/14119/en/

[billko]

---

@BowenM wrote:

---

@billko wrote:

---

I would never tell a newbie to C rogramming to put all the stuff in one function because it's easier than creating a function for each... well... function.

Besides, you're NOT ensuring dataflow.  Sequencing and dataflow have some things in common, but they aren't the same.

---

Of course you wouldn't.  To a "C" coder, each frame is a function. It does one specific purpouse with each  sequence local is an input/output to that function. It is procedural code.

---

I think you missed my point.  What I was trying to emphasize was whathappens when you encourage bad practices.To someone new to C it would much simpler just to cram everything into one function.  It would take some time to teach him to break everything up into functions, but that is the "correct" way to do it.  Now imagine this person continued coding without reading any books or taking classes or tutorials and he continued to write his programs in one function because he never learned how to make function calls.  How difficult it would be to troubleshoot.  I know that's an unlikely scenario, but that's only because C is pretty much ubiquitous in the world of programming and there will always be someone to help this person do it the right way.

Similarly, encouraging someone to use an SSS instead of encouraging him to understand what a state machine is, is to lead him down a path he may never recover from.

And - IMHO - state machines are even better than SSS in terms of organization because it is very easy to see what goes into and out of each state.

[edit] However, I don't advocate removing it for compatibilty.  Just make it a lot harder to find.  😉 [/edit]