Val Brown

I think it's all of that and more.  Even when embracing some aspect of the new the beliefs and commitments almost demand that there is a return to the familiar. So no matter how easy, intuitive, fluid, capable, amazing the visual IDE, until it can generate text-based code it means nothing -- because text-based code is REAL programming....

Yes, it's interesting.  The basic argument against visual IDEs is: "I grew up using text-based coding and so it's easier for me."  While that observation may well be germane for the individual, it really is fairly ludicrous as a general statement.  It would be like saying: "I first learned to program FORTRAN so, if I really want to get the job done, I'll go back to what I know".

The Big Battleship Admirals resisted Aircraft Carriers even Torano, sinking Bismark and the other German Capital ships, as well as Pearl Harbor.  Data rarely convinces -- it frequently just hardens the arteries and attitudes.

I mean, come on NI.  Why wouldn't you do that for the FP as well? 

Functional programming is what I "grew up with" as a paradigm so F(x) means almost literally that NOTHING Fxxxx with your x except you...

Or at least that's how it was explained to me by a mathematically oriented physicist programmer.....

Hi

 

I have tried to make a small UML diagram in the Symbio GDS, but it fails to generate the whole code. It only make a part of it and then turn into an error. I have sent the Error code but haven't got an answer yet:-(

Am I doing something wrong? Se attached pictures.

 

Hope for help;-)

 

Edit: I use LV2013 and GOOP GDS4.6

 

Regards Bjarne

 

UML symbio.PNG

Generated code.PNG

Mikhael is working on validating a fix for this: ie he has a fix that is undergoing further testing before release.

...and I love the icon Robby. http://en.wikipedia.org/wiki/Robby_the_Robot

I suggest you all start using the new Event Inspector Window. On the left-most column you'll see a sequence#. This is a globally unique number that each event has and is used to order the events. This is a new (behind the scenes) feature of LabVIEW 2013 that guarantees that events now will always be handled in the order they are fired.

RIght, probably some form of 

"upfront" pipeline to set the appropriately numbered flag...

Absolutely!  It was great meeting you as well. 

I've heard it said that Von Neumann's architecture is the single worst thing ever to happen to computer technology. Von Neumann gave us a system that Moore's Law applied to and so economics pushed every hardware maker into the same basic setup but there were other hardware architectures that would have given us acceleration even faster than Moore's Law. At the very least we would have benefited from more hardware research that broke that mold instead of just making that mold go faster. All research in the alternate structures dried up until we exhausted the Von Neumann setup. Now it is hard to break because of the amount of software that wouldn't upgrade to these alternate architectures. 

 

Don't know how true it is, but I like blaming the hardware for yet another software problem. ;-) 

It's exactly true.  I remember all of the ideas of that presentation back IN that time, many before, and have been amazed by the linearity of much of the rest of CS since that time.

Hmmmm, well everyone has opinions don't they.  FWIW I think 2013 is very stable and, again FWIW, I don't have to deal with DAQ so I can't really say much about ShaunR's perspective, except to sympathize.  So my experience: I've migrated a very large and complex app to 2013 (having nursed it all the way through 5x) and this was the easiest migration ever.

LabVIEW 2013 has crashed twice on me so far. Sorry...

Hmmm not on me so far...

Yes a good example of the difference between a feature and a bug.

Feature: Something the program does

Bug: A feature someone doesn't like

There may well be a central pipeline feature now that is implemented as a front end to all queuing operations.  This could give a central timing function for all internal dispatching done by LV. This is a legacy solution I've seen in other environments a long time ago, in galaxy far, far away....

Examples don't help with figuring out when an actor should be used.  An example can show how to implement them, but there are way too many variables for me to tell someone when they should use an actor.  When do I use actors?  Any time I have multiple processes that need to run concurrently.  When should you use actors?  When the business conditions are suitable to do so.

I disagree on this but for the moment will follow your line.  If I ask "When will the business conditions be suitable for me to implement Actors?" the answer is: Quite likely, never.  But I'm a special use case: single product, single developer (soon to bring on a new programmer so I can just architect), with a deploy history stretching back to LV5 so LOTS of legacy code.  Refactoring even some of that to incorporate Actors would be a fairly substantial effort at this point, even if it made definite sense to do so.

On the other hand, me seeing concrete examples of when others deliberately chose to implement Actors to solve certain problem or design specs can be instructive to me in understanding better how and when Actors might become time/cost effective for me to implement within the overall enterprise.  Hearing the reasoning behind making the choice to implement Actors instead of other approaches in specific examples is even more instructive.  So examples would help -- at least help me -- a lot.

...there are no general rules for when they are and are not appropriate.  It's appropriate if you can build it so it fits into your design and behaves how you need it to behave.  It's like asking when it is appropriate and is not appropriate to use classes.  There are no technical reasons not to use classes, and there are no technical reasons not to use actors. 

This precisely why an EXAMPLE would help.  Presumably IF there were general rules THEN you could just specify those and pointe finale. 

Right, a new AA: LV Aligners Anonymous....

Alone? No, this looks like a support group forming. I resisted the urge to go realign every VI in a project after moving from a XP to Win7 machine (yea, I use the default fonts).

NI does that intentionally just to see if you're paying attention.  They can tell when they hear the "crash".....

Okay I don't think I'm as bad as some of you guys but I too find my self moving things one pixel at a time some times to line them up nicer.  But there are a few times that I hate the terminal choices used by NI.  Here are two times that I can think of that irk me.

 

 

 

Why do these not line up?  Seriously NI?  Seriously?

But I would certainly agree that anybody claiming AEs to be generally inferior to classes is simply ignorant. They can be created and used very successfully, if you have your mind properly wrapped around them. I would however hesitate to claim that they are worth to learn at this point instead of LVOOP. As an additional tool in a programmers toolkit they are however still a very valuable and powerful addition to any LabVIEW programmer expertise.

I'm completely on the page with you in most everything you say on this topic; however, I might use the word "prejudiced" instead of, or perhaps in addition to, "ignorant".  One thing I would disagree with is you last point.  IF you come from an OOP background -- eg having grown up in a contemporary CS program, THEN FGVs become an additional tool; however, IF you don't have that background and/or are a domain specialist THEN my strong suggestion would be to begin with FGVs.  They are a much easier starting point given the history of LV and the multitude of legacy examples that are available from a number of sources.

If you're not from an OOP background AND you're a domain specialist who just wants to get the bloody thing done, FGVs are the way to go.  In any event, you and I are good examples of that, as are many, many others.

I still find FGV to be a useful tool even in current code.

I do too FWIW.

One approaches queues state, the other queues messages.  It's analogous to the difference between Mealy and Moore machines.  Either CAN be converted into the other and pass a "Turing Test" of equivalence so, if you take an abstract enough view, there is no difference functionally.  This is much more of a by ref implementation whereas the other is more of a by val implementation.

Historical usage in the LV community, however, does support the idea that a QSM does not use the LV structure of a queue (basic function) because there is one "super loop", whereas a QMH does use the LV structure of a queue as a means to transport messages between two parallel loops, which may or may not be explicitly coded in the same VI.

For me the queue structure is what defines a QSM and it is different from a QMH.  The primary example of a QSM for me was the original shipping example of the ASPT.  It had a while loop that held a case structure that was fed by a build array of boolean outputs that was searched for index, that was incremented and then typecast to an enum.  Each case of that structure (from FP controls) held used build array to queue as sequence of states that was pipelined to another for loop that dequeued the array of states to be run.  The queue was the list (or queue) of states to be run in each iteration of the enclosing while loop NOT the mechanism of using an LV queue.

Yes, tough to put into words but it was a primitive form of "producer-consumer" based on the UI because, well, that was about the only way to implement something like that back in LV5.  And it was "hard on the eyes" as the Chinese would say, since there is no good word for "ugly" in Chinese.

For me a QMH would be producer-consumer kind of construct that uses LV queues.  A QSM queues states (within the each state/iteration of producer loop, whereas a QMH uses queues originating in one while loop to communicate to, or message, another loop. The difference lies in the communication used as well as there being more than one while loop, each running in parallel.

I apologize for not going back and editing my original post but I think everything got the point regardless.  I'd like to add another aspect to this thread: viz, I strongly suspect that the majority of LAVA members who want to keep the FGV|AE distinction "grew up" learning OOP in a CS degree program and most probably with a focus on C++ and/or JAVA.  I didn't.  In fact, I never went to CS courses and I learned to program in PL/1, then onto C and Unix.  I even remember when Linus's Unix (or LI-nix) first came out.

So why am I asking about what you "grew up" learning?  Because I think it's exactly on target that the overwhelming majority of LV programmers are domain expert (or domain specialists) and not CS degreed professional programmers.  LV is easy to learn; and, yes, it's easy to learn badly.  So why learn/use (what I'm calling) FGV instead of other solutions?

1. There is an extensive "library" of already developed code in the larger LV community based on them.

2. They are clearly dataflow and by-val, unless one violates the encapsulation (as what happens when an originally lean and tight FGV gets "overloaded" inappropriately.

3. They are easier to learn and utilize IF you're a beginning to intermediate LV programmer who is a domain expert/specialist and NOT a programmer who has learned to base their fundamental paradigm around by-ref implementations.

Yes, this is LAVA -- so everyone here is presumably "advanced" and, having been programming in LV for more than a decade and doing things with the language that others thought impossible, I believe I'm also advanced; and, perhaps most importantly, I believe that it is critically important to remember the core market of LV.  And that is domain expert/specialist who are NOT CS degreed professional programmers who provide LV (and other language) based implementations for others as their primary business.

And, yes, I am strongly considering becoming CLA, primarily so that I can attend the CLA summits.  I only program for myself (my own company) and have no desire to become a LV consultant or wiring business for hire so the CLA as a credential doesn't hold any particular meaning for me, except that it would allow me to fully participate in very interesting discussions!

Anyway, sorry to be long winded about this.  Climbing down off the soapbox now so I can have some  .

Semantics aside...other functionality that can be done is stuff like WORM.  Where a global can only be written to once then it will generate an error if it is written to again.  Many of the pitfalls of a native global exist in these other VIs, but allowing added functionality, and also adding other debugging tools helps to make sure you don't shoot your self in the foot.  But it can still happen.

Did uou know that WORM was the original construct that was implemented as CD-Rs? It was originally aimed at being Write Once Read Many as a "real world" persisting physical record that could NEVER be written to again, not just within one instantiation of a running program.

I was struck by a number of things at NI Week 2013 but one in particular I want to comment on.  Nancy Hollenbeck did a marvelous job of presenting on FGVs, Action Engines and DVRs.  It was really a great presentation but I did have a thought about one aspect of what she presented.

Nancy drew a distinction between FGVs and Action Engines, essentially pointing out that a "bare" FGV is really just a global and, therefore, doesn't protect against race conditions, etc, etc.  From that perspective an Action Engine is an FGV that, because of its "Solitron" like structure does preclude race conditions.  OK, fair enough and clear; however, I had a different thought.

FWIW I think we should call a "Nancy" FGV a DGV means a DYSFunctional Global Variable because it has ALL of the liabilities of a global AND is far, far slower to execute.  That would allow us to agree that a FGV is an Action engine BECAUSE it is functional, etc, etc.

OK, I do get into semantics at times so I apologize and Nancy it really was a fabulous presentation.

I'd like to look at the video before making further specific comments (yes I was there) but one thing was abundantly clear: viz, it didn't work that well for the two of you to present in the same time slot.  If you really wanted to do something together then it either should have been a joint presentation or more of a panel discussion.  There were different slants in each section -- unavoidable given the format used -- and that decreased IMO the overall precision and clarity of what each of you were trying to communicate.

If I can summarize this issue -- hopefully correctly! -- it seems that you essentially want LV to be a "standard" byref implementation of OOP.  It isn't.  It's a byval implementation but, as AQ and djdpowell  point out, there are numerous ways to use it to effect the same kinds of programs, they're just not "pure" classic byref OOP.

As AQ suggested, read the white paper: it will help clarify this issue quite a bit for you.

....or include it in the built EXE....