Remove the stacked sequence structure from LabVIEW.

[GerdW]

Hi Stel,

(1) To have project-related palette views is a nice idea. Post it in the idea exchange!

(2) This will interfere with NI's licensing policy. They never have updated older LV versions (apart from SP1 releases) to include features of newer LV versions - and I don't think NI will change its behaviour in this point. When you want to use new features you have to upgrade.

The same applies for new hardware: new hardware is supported by new DAQmx driver version. But newer DAQmx versions only support the latest 4 (or 5) LV versions…

[CoastalMaineBird]

It's a bit hypocritical to claim others aren't describing why they hate it well enough to your taste while you offer no reasoning for why you enjoy it.

Call it what you will, but I'm not the one advocating a major change that will break your code.  I'm not trying to force you to use it.

But, what is it about the SSS that you find so incredibly useful?

It's not that it's "incredibly useful" - it's just another tool in my toolbox.

I use it a lot in window init code - when a pop up window comes up.  I have one here that has 17 frames of init code, then the event loop in frame 18, then 5 frames of shutdown code.  Could I do that without it?  Sure - there's always another way.  But why?

I don't see how someone who doesn't understand the sequence will understand a state machine any better.  I use state machines all the time - they're a good way to deal with external devices. But I don't see how it's any simpler to use a while loop with a case structure and some invented enums, rather than a sequence.

Would you have had any problem without them existing? 

I suppose not.  I could use a while loop with "i" tied to a CASE selector, and a STOP flag of some sort. And have to make sure that when I delete case 3, that I go to the trouble of renumbering case 4, case 5, and the rest.  I just don't see how that's an improvement.

Were they necessary for the application you were using or were they just one possible way to do what you wanted, without evaluating whether they would have been more or less efficient than the alternative solutions?

Sure, I evaluated it.  It is the best tool for the job in places. Same as the FFT or the FOR loop.

I call it "dogma" because it's often presented, as it has been here, as incontrovertibly true, without any evidence.  It's just something one believes.

[CoastalMaineBird]

The idea of user configurable palettes is a good one for two reasons -

(1) users could set up their preferences to improve their work efficiency, and in this way palettes could be configured specifically for projects, old and new.

There's value in that, as I could get remove the statistical stuff and the report generation stuff that I never use, and clean up my palettes. But the downside is that if I move to your machine, then I don't know what you have removed, and where you have put the SCAN STRING for TOKENS function that you never use and I need. So there would have to be a way to get to the standard palette - use the ALT key, or some other menu item, I would think.

[Stel]

Reverting to 'everything in' palletes I expect would not be an issue.

In fact if NI were really cool they could set LV up such that a user could have the option to log-on to LV (if set up as such and working within a network).  This would allow the local LV client to check a server and use the particular user's preferences to set up menu and palette options along with those deemed best for any current/local projects say.

[BaptisteC]

I use it a lot in window init code - when a pop up window comes up.  I have one here that has 17 frames of init code, then the event loop in frame 18, then 5 frames of shutdown code.  Could I do that without it?  

You don't need a while loop or a state machine, you need a FOR loop and an array of Enum or string.

Sure - there's always another way.  But why?

Because with a for loop and an array ou can:

 - Tranfer data from one fram to another without these horrible sequence local

 - You have the condition on top off you code which auto-document what you are initializing at the moment

 - You can get rid of one of you frame of initialisation by just changing the array (no need of case or disable structure)

 - you can program which kind of initialisation you want to do based on context

I don't see how someone who doesn't understand the sequence will understand a state machine any better.  

- You have the condition on top off you code which auto-document what you are initializing at the moment (what i talk about is not really a state machine tho, it is much easier to implement)

I use state machines all the time - they're a good way to deal with external devices. But I don't see how it's any simpler to use a while loop with a case structure and some invented enums, rather than a sequence.

Because:

 - Tranfer data from one fram to another without these horrible sequence local

- You have the condition on top off you code which auto-document what you are initializing at the moment

-  You can get rid of one of you frame of initialisation by just changing the array (no need of case or disable structure)

 - you can program which kind of initialisation you want to do based on context

I hope it helps understanding why those SSS should be removed and therefore save me all the future project in which a customer hand me some code and ask me to refactorise it AND IT IS FULL OF SSS !!! ARG!!! KILL ME NOW !!!

[rolfk]

---

@Stel wrote:

The idea of user configurable palettes is a good one for two reasons -

(2) newly developed items by NI could be released retrospectively for older versions of LV and added to palettes, so that improved functionality could be added to projects written in older versions without the need to move the entire project to the most current platform

---

The palettes are in fact user configurable already. The VI Package Manager makes use of that and if you want to be fancy you can even go into the palette editor yourself and change things. Yes the palette editor isn't a very user friendly part of LabVIEW as it actually was introduced in LabVIEW 2.something and a lot of extra stuff has been added to the palettes since and the palette editor has been mostly hacked to support them in some way or the other rather than considering a user friendly rewrite of the whole thing.

And retrofitting new features to older LabVIEW versions is pretty independent of user configurable palettes. OpenG Tools generally support several previous versions of LabVIEW at the time a Toolkit is released and get seemlessly added to the palette of all the LabVIEW versions a Toolkit claims to support. NI won't likely support older LabVIEW versions when they release a new Toolkit or feature for several reasons, one of them being focusing of their developer resources on supporting the newest versions rather than trying to back port new tools to old LabVIEW versions.

[Stel]

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!

[Stel]

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!

[CoastalMaineBird]

Thanks, BaptisteC, for articulating your objections, rather than just saying NO! NO! NO!

You don't need a while loop or a state machine, you need a FOR loop and an array of Enum or string.

... AND you need a CASE structure.  I don't see how that's an improvement over a sequence.

Because with a for loop and an array you can:

 - Transfer data from one frame to another without these horrible sequence locals

I don't use them much but I don't see what is "horrible" about sequence locals.  Yes, it's a pain to physically arrange them, maybe that's what you mean.

I don't have much need to transfer from one frame to another, anyway.

You have the condition on top off you code which auto-document what you are initializing at the moment.

Except that it's not "auto" at all.  You have to name things, and then put stuff into the right "frame".  The particular example I cited, with 17 init frames - there is not a convenient label that would describe everything in frame 5. The sequence is more of a space-saver than a sequence enforcer.  When I add something new, it needs to be initialized, it just goes into some frame before the EVENT loop.  I suppose I could separate it out into 50 frames, with 50 different names, but that means that I am trying to take over the scheduling.  Now, I just let LabVIEW sort it out and make the best choices.

- You can get rid of one of you frame of initialisation by just changing the array (no need of case or disable structure)

That doesn't seem easier than "DELETE FRAME" .     I see no advantage.

- you can program which kind of initialisation you want to do based on context

Some of that I do with case structures inside a frame.   If TEST TYPE = TEST A then INIT A else INIT B.

I appreciate your articulation of your objections, but I am unconvinced.

Can it be overused, misused, and abused?  Sure - so can local variables, global variables,  and the Bessel Filter. 

The fact that children are not capable of operating cars correctly is not a good reason to ban cars.

Perhaps you would like a software developers' license?

[natasftw]

---

@Stel wrote:

The idea of user configurable palettes is a good one for two reasons -

(1) users could set up their preferences to improve their work efficiency, and in this way palettes could be configured specifically for projects, old and new.

(2) newly developed items by NI could be released retrospectively for older versions of LV and added to palettes, so that improved functionality could be added to projects written in older versions without the need to move the entire project to the most current platform

---

If you're worried about efficiency, you're generally using Quick Drop over the palettes.  You're also not likely to be looking at reconfiguring palettes for each project.

Things already can be added to the palette via the user library.  You're not creating functionality here.  You're also suggesting you think it's in everyone's best interest for development to focus on being retroactive rather than proactive.  Personally, I'd prefer NI work on new features and ways to make things easier than worrying about how to implement a new feature into LabVIEW 8.6

---

@CoastalMaineBird wrote:

It's a bit hypocritical to claim others aren't describing why they hate it well enough to your taste while you offer no reasoning for why you enjoy it.

Call it what you will, but I'm not the one advocating a major change that will break your code.  I'm not trying to force you to use it.

But, what is it about the SSS that you find so incredibly useful?

It's not that it's "incredibly useful" - it's just another tool in my toolbox.

I use it a lot in window init code - when a pop up window comes up.  I have one here that has 17 frames of init code, then the event loop in frame 18, then 5 frames of shutdown code.  Could I do that without it?  Sure - there's always another way.  But why?

I don't see how someone who doesn't understand the sequence will understand a state machine any better.  I use state machines all the time - they're a good way to deal with external devices. But I don't see how it's any simpler to use a while loop with a case structure and some invented enums, rather than a sequence.

Would you have had any problem without them existing? 

I suppose not.  I could use a while loop with "i" tied to a CASE selector, and a STOP flag of some sort. And have to make sure that when I delete case 3, that I go to the trouble of renumbering case 4, case 5, and the rest.  I just don't see how that's an improvement.

Were they necessary for the application you were using or were they just one possible way to do what you wanted, without evaluating whether they would have been more or less efficient than the alternative solutions?

Sure, I evaluated it.  It is the best tool for the job in places. Same as the FFT or the FOR loop.

I call it "dogma" because it's often presented, as it has been here, as incontrovertibly true, without any evidence.  It's just something one believes.

---

I'm not advocating for its removal.  As you see, I have been on the sidelines for most of this discussion.  I'm just suggesting it's hypocritical to stay on a perch telling others how they're wrong for doing exactly what you're doing.  One could argue the code is already broken and the change would force a fix.  One could also argue the use of SSS is valid.  Here, you're presenting something as "invontrovertibly true."  But, it's alright because it's your opinion rather than theirs.

I have many tools in my box that go unused, both in coding and in physical toolboxes.  I could easily do without many of them.  That's why I ask what you find useful.  Simply stating "it's another tool" doesn't suggest it has valid use cases.  You follow this with a question that really doesn't offer any benefit.  I could just as easily as you "why" you choose to use the SSS here instead of the other methods.  If it's redundant functionality, the better question is why do both exist?  What is the SSS providing you here that you couldn't gain with the other option?  If it is offering you no benefit, why are you using it?

I don't believe someone that doesn't understand the SSS will understand the state machine.  However, I do believe spending the time to understand how to implement the state machine will mitigate many of the problems experienced by dropping the SSS.  The small amount of added difficulty in implementation forces the user to learn something about the structure.  This helps push learning versus simply expecting something to work as desired.  I didn't suggest the state machine was simpler than the SSS.  In fact, I suggested the opposite.  But, the overall frustration trying to debug a poorly designed SSS architecture outweighs the frustration putting together a state machine and debugging it as well.  It also helps teach better programming.

If you look at a terrible way to replace SSS, I'm sure we'd expect to see this being a pain to deal with.  Conversely, I could show a number of examples where SSS's complicate code.  Then, I can ask how that's an improvement.  I can show where SSS's are useless as the data flow is already enforced and ask how that's an improvement.  But, that wouldn't help my point any more than your usage of a terrible replacement helped your point.  Even if we used the terrible architecture you suggested to replace this, removing a case would be as simple as wiring through the data and performing zero calcuations.  But, why would you ever use this method when you know it'll be difficult to manage the case structure and you could easily implement an enum that would allow you to quickly add/remove cases later?  Offer realistic alternatives to the code and it becomes a far more worthwhile comparison.

You call it dogma because you disagree with it and it's easier to use a term in a derogatory manner than to actually present your point in a meaningful way.  It has nothing to do with how their view is being presented.  You're presenting yours in the same manner.  If we dismiss all "dogma," we'd need to dismiss your point of view just as quickly.

Ultimately, your points you've made in this thread are "you can also perform this function with the SSS.  Therefore, there's a need for the SSS."  That's not the definition of a need.  That's the definition of redundancy.  You complain about others not articulating their point.  Articulate your point.  Show me something, anything, that shows there is a valid use for SSS that cannot be handled just as well by another structure.