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.....

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

RIght, probably some form of "upfront" pipeline to set the appropriately numbered flag...

Absolutely! It was great meeting you as well.

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.

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....

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.

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....

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

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 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 . 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....