GDS(Goop Development Suite)

Highlighted

Re: By reference vs. By value

I didn't think this would turn into such hot discussion.!

However, I get that, though people start off with by-value, as the projects gets large-scale then people naturally looks for by-reference changes in it.  Thanks AQ for the caution during that case

AristosQueue wrote:


mutual exclusion protection offered by references as a last-resort shield

0 Kudos
Message 11 of 18
(1,892 Views)
Highlighted

Re: By reference vs. By value

Ajayvignesh_MV wrote:

However, I get that, though people start off with by-value, as the projects gets large-scale then people naturally looks for by-reference changes in it.  Thanks AQ for the caution during that case

I find that "actors"**, or whatever one calls an asynchronous loop interacting with messages, handles scale, rather than by-ref objects.  Of course, an actor is basically a kind of by-ref object.  An actor is active (rather than passive like a DVR), so it can do things like publish information rather require polling.  For common resources I tend to have a by-value "driver" object, contained in one "resource actor", with the actor's reference being shared.  

** "actors" in general, rather than Actor Framework "Actors" specifically.

Message 12 of 18
(1,892 Views)
Highlighted

Re: By reference vs. By value

Yes. This. Exactly.

Use the concept of actors -- not necessarily AF... there are other frameworks out there, or even a basic producer/consumer pair of loops serves this purpose -- instead of by-ref objects. That's how you achieve scale and safety simultaneously.

0 Kudos
Message 13 of 18
(1,892 Views)
Highlighted

Re: By reference vs. By value

MinhPham wrote:

Either way has its pros and cons, personally I dont think ones can be better than other.

The science research on this topic says that there can be one that is better than the other for the general case. For you as a specific programmer in your specific niche, it may be inverted, but if on any given day you work on a random project X with a random team Y, there's a clear winner that becomes more clear as the parallelism and the size of application increases.

I've only been banging this drum in the LV community for the last 6 years, and my reach into Asia is very limited, so I expect to need a lot of time to change hearts and minds. But I'm going to keep drumming... this is not a LabVIEW special thing... all of computer programming is coming to the same realization. That's why you see keywords "async" and "await" in the newer C# standards. That's why Hadoop has risen to such prominence. Actor-oriented systems are going to dominate in the future because they work flat out better in a multicore/multithreaded/distributed world.

MinhPham wrote:

but not the actor frameworks as I found it very messy to use in projects (might be it is just me?)

It is not just you. There are many developers that have had trouble adjusting to the mental model of actors. But there are plenty of newbies who have picked it up on day one and done amazing work with it. And not just the AF -- there are many other good actor-oriented LV frameworks available in the world. LapDog is over on LAVA; DQMH is available from Delacor. And there are others. I encourage you to find one that you like and use it.

The objections you raise are *exactly* the ones raised by procedural programmers when first confronting OO.

The paradigm changed when CPUs became multithreaded and multicore, folks. Architectures need to change to keep up.

Message 14 of 18
(1,892 Views)
Highlighted

Re: By reference vs. By value

drjdpowell wrote:


I find that "actors"**, or whatever one calls an asynchronous loop interacting with messages, handles scale, rather than by-ref objects.  Of course, an actor is basically a kind of by-ref object.  An actor is active (rather than passive like a DVR), so it can do things like publish information rather require polling.  For common resources I tend to have a by-value "driver" object, contained in one "resource actor", with the actor's reference being shared. 

** "actors" in general, rather than Actor Framework "Actors" specifically.

drjdpowell,

       That's a completely new view and it's taking time for me to digest it (I mean actor here).  May be because, I have been using the polling mechanism (using Queued State machine to share messages between the asynchronous loops) so far and I'm still not finding actors in my feature projects.  I think, you're inherent to the same caution of AQ while using by-reference, where you have the actor which protects itself during mutex operations.  Is that correct?

AristosQueue


DQMH is available from Delacor.

AQ & drjdpowell, please correct me if I'm wrong here.  I have once read about DQMH and it's primarily based out of user events (with data) in LabVIEW.  The user events which is generated by other asynchronous loop, works like an actor here.  Isn't it?

AristosQueue


The objections you raise are *exactly* the ones raised by procedural programmers when first confronting OO.

AQ,

   I find the similar kind of objections like AF looks clumsy with lot of messages in my project blah blah blah.. though I haven't realistically used it in any project.  I don't want to risk taking it in my project unless I am sure confident about completing the project with actors.  How could that gap between such objection and acceptance for the people could be closed?  Do you have any suggestion like looking at some reference proejcts?

0 Kudos
Message 15 of 18
(1,892 Views)
Highlighted

Re: By reference vs. By value

Ajayvignesh_MV wrote:

AQ & drjdpowell, please correct me if I'm wrong here.  I have once read about DQMH and it's primarily based out of user events (with data) in LabVIEW.  The user events which is generated by other asynchronous loop, works like an actor here.  Isn't it?

The message handler itself is an Actor.  Terminology sometimes gets in the way of these discussions.

Whether to use User Events or Queues for message transport to the QMH/Actor/Module/etc is a whole other discussion with very good arguments for each side.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
0 Kudos
Message 16 of 18
(1,892 Views)
Highlighted

Re: By reference vs. By value

Ajayvignesh_MV wrote:

How could that gap between such objection and acceptance for the people could be closed?  Do you have any suggestion like looking at some reference proejcts?

There is a brand new 3-day customer education course available from National Instruments.

    http://sine.ni.com/tacs/app/overview/p/ap/of/lang/en/pg/1/sn/n24:22418/id/3459/

There are reference projects that ship with LabVIEW

    File >> Create Project ...

There are several examples written by others in the AF forums

    http://ni.com/actorframework/

Including this intro tutorial from a customer

    https://decibel.ni.com/content/docs/DOC-42227

The materials are out there, and in bulk... just as they were with OO. But still, the resistance to OO was high. Some people were willing to try it immediately just because NI and the rest of the computer science world said, "You should do this." But everyone else took the same "wait and see" approach... except they never finished waiting. The only thing that I ever found to be successful was to find the youngest new hire in a company, teach them OO, then let them embarrass their elders by producing something substantial with greater fluidity than the traditional approach. Then the elders would grudgingly start learning it.

I observe this same resistance gap occurs with every programming paradigm shift. A few of the old guard jump across quickly, then the new hires, then the rest of the old guard. Collectively, I see our industry attract major early adopters and extreme laggards, and very little in between. That's my annecdotal observation. It certainly isn't scientific survey of adopters.

Message 17 of 18
(1,892 Views)
Highlighted

Re: By reference vs. By value

 


@AristosQueue wrote:

I've only been banging this drum in the LV community for the last 6 years, and my reach into Asia is very limited, so I expect to need a lot of time to change hearts and minds. But I'm going to keep drumming... this is not a LabVIEW special thing... all of computer programming is coming to the same realization. That's why you see keywords "async" and "await" in the newer C# standards. That's why Hadoop has risen to such prominence. Actor-oriented systems are going to dominate in the future because they work flat out better in a multicore/multithreaded/distributed world.


Hello , AristosQueue

 

According to my personal understanding, you also have a large number of enthusiastic fans (including me) in Asia, especially in China. However, due to language communication problems, there are many communication barriers, and most people speak less in the community, which is silent. Most people!

 

In addition, there are many developers in China who are very eager to learn and master OOP and AF. Most people use the Chinese version of object-oriented programming materials in many languages ​​such as Java and C#, so they have many misunderstandings and prejudices about passing values ​​and references. , Seriously restricting the reasonable application of these technologies in actual projects (here also includes myself).

 

I think this requires local community technicians and NI China to do more localized translation and promotion work, because most engineers prefer the Chinese language version of the learning materials and materials. At present, NI’s excellent AF courses and related technical white papers (such as Using the Actor Framework 3.0 in LabVIEW, OOP and Interface Decisions Behind the Design) are all written in English, which restricts the popularization and promotion of relevant advanced knowledge in the Chinese and increases the learning curve.

 

According to my personal assessment, the gap between our OO application level and the level of the English community is between five and seven years, and a considerable number of people resent and oppose OO and AF, which have seriously affected the development and application of high-end programs. 

 

I am also learning from you to vigorously promote OO and AF technology in China. More community participation allows everyone to improve faster. I also hope that someone can master these powerful abstract programming tools in technical engineering, and use LabVIEW to solve more and more complex Technical issues.

 

Of course, I also hope that AF can become a built-in primitive of the LabVIEW programming language as soon as possible!

 

My community posts less, if there is something wrong or impolite, please bear with me!

 

Thank you!

0 Kudos
Message 18 of 18
(79 Views)
Reply
This is an open group. Sign in and click the "Join Group" button to become a group member and start posting.