I agree,
After years of programming with Labview I'd summarize the discussion with
some of the "againsts and fors" already stated and one new thing, namely
documentation.
First however I would like to point out that
It always gives me great pleasure and pride when I utilize the fact that
with Labview, the program core idea can be made visible in one screenshot.
This is practically impossible with any other programming language, at
least
with any textual one. It is becoming more and more widely accepted that
Labview G is the best programming language there is.
It amazes me considering this capitalistic "modern" world of robber-like
opportunism, that Labview base package is so inexpensive.
Many thanks to NI for a truely value-adding workframe.
As the software lifetime is often short I typically use the "good
programming"
features of Labview for pedagogical purposes only. The hierarchy is
not a holy word for me, I have found it impractical in time critical
programming, typically for small applications (250k).
For me the modularity is best served in very simple basical functions like
"append_Excel_sheet.vi" or sth like that.
Ok, back to the issue,
1. against: Sequence locals really turn out a horrible mess,
I always use some way other if sequence locals were
needed.
2. for: In small applications you want to get ready fast and nobody is
interested
in the code itself.
3. for: It is nice to write down the code explanation inside a sequence
frame
along with the code to put up a documentation for a small
program.
If you keep it simple (the init purposes for example) sequence frames
are quite OK,
Martti.R
Oulu, Finland
fairhairedwineboy wrote:
> I'm sorry. I simply do not agree that sequences are necesarily that
> hard to follow and understand. I have troubleshot lots of code with
> sequences and do not find them any more difficult than those with tons
> of subvis.
> Do not misunderstand, I like subvi and use them extensively. However,
> A blanket policy that sequences are bad - no way - use them if you
> like and don't waste a lot of time wondering if you should or
> shouldn't.