Feedback Requested: Daklu's NI Week presentation on AOD

[Daklu]

Edit - Mark Balla recorded the session and posted the video.  Instructions for downloading it are here.

 

--------------

 

First of all, Thank you to the Lava community for coming to our NI Week presentation!  We had a great turnout and I was shocked at how many people raised their hands when I asked who read the Lava forums.  I hope you found the content informative and useful.

 

For those of you who attended, I'd appreciate it if you could help me improve the presentation by giving me your honest feedback on my part.  I'm not fishing for a pat on the back; I really what to know what parts you found most helpful and what parts I need to work on improving (or eliminate altogether.)  Everything is fair game--the content, the look of the slides, how I presented, what I was wearing, etc.  What I too repetitious?  Did I not spend enough time explaining something?  Was the message cohesive and coherent?  If you thought it, I want to hear it.  (Yes, I'm looking at you lurkers...)

 

My primary goal with this presentation is to help people understand what it means, at an abstract level, to do actor-oriented programming.  My secondary goal is to point them in the right direction regarding implementing actors.  Some of the areas I think need to be improved:

 

-I don't think I did a very good job explaining the principles of hierarchical messaging.

-I skipped around on a few of my slides and that may have caused confusion.

-A Venn diagram probably isn't the best way to illustrate the Actor Model.

 

If I were to expand this into an full hour presentation, what topics should I cover in more depth?  My thoughts:

 

-Topologies.  Maybe animating messages between actors would help illustrate the tradeoffs between direct and hierarchical messaging?

-I had a couple requests for more discussion about Command Pattern messaging.  Would this be helpful?  The command pattern could be an hour long discussion all by itself.  How much needs to be covered?

-Do I need to go into more details about the issues with QMH/QSM and show how actors are different?

-I glossed over actor Exit conditions fairly quickly; that might need a bit more explanation.

 

Thanks,

Dave

[hooovahh]

I'd be glad to give detailed feedback. But I will hold off a detailed response until after I see slides or the video. I can't remember all the things said but one of those things will help jog my memory.But know I left that session convinced I won't use the Actor Framework. Again I can give details later but I kept having this feeling that NI's AF had many restrictions, steep learning curve, restricted debugging, and didn't add much over other Actor/Asynchronous Engine designs.Another big turn off was the semantics between an Actor and QMH. I realize it is a heated topic, but I don't see the big deal and to be honest this could be my own opinion because I haven't had 1-on-1 discussions to hash out the and understand the topic fully.Ok one more thing. Other diagrams would help but I don't remember having a problem with what you had.

[Michael Aivaliotis]

Unfortunately, i did not get to see your presentation because it was at the same time as mine However, I will devour Mark Balla's video of it. The feedback I heard from others was that each of you (David and Staab) could have had your own dedicated sessions. So not sure how you can add more content. But I will reserve judgement until I see the video.

[Val Brown]

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.

[Daklu]

Thanks for the responses so far.

 

Another big turn off was the semantics between an Actor and QMH. I realize it is a heated topic...

 

I wouldn't call "the semantics between an Actor and QMH" a heated topic.  I can get... energetic... when I'm trying to explain the difference to people, but I don't get angry about it.

 

The reason I talk about the differences between a QMH and an Actor is to try and show it's not just semantics--there are huge differences in how external entities interact with a QMH compared to how they interact with an Actor.  Your comment indicates I didn't do a good enough job communicating that message.  Either I didn't explain it well enough or you have a different idea about what a QMH *is* than I do.

 

 

The feedback I heard from others was that each of you (David and Staab) could have had your own dedicated sessions.

 

Yep, that's probably true; however, I pitched my presentation for NI Week last year and it was rejected.  I don't have any reason to believe it would have been accepted this year either.  If Staab hadn't asked me to participate in his session I wouldn't have done anything.

 

 

one thing was abundantly clear: viz, it didn't work that well for the two of you to present in the same time slot.

 

Yeah, I got second hand feedback that a few people thought the switch from my presentation to Staab's was a bit jarring.  We assumed people knew OOP and were passingly familiar with the AF, but didn't really understand AOD.  My part attempted to explain the principles of AOD to help devs design their app correctly, and Staab followed with details to help people implement their app correctly using the AF.  Given that we were in the same time slot, I can't think of any way we could have lessened the jolt.  Any ideas?  (That's an open question to everyone.)

[ShaunR]

Thanks for the responses so far.

 

 

I wouldn't call "the semantics between an Actor and QMH" a heated topic.  I can get... energetic... when I'm trying to explain the difference to people, but I don't get angry about it.

 

The reason I talk about the differences between a QMH and an Actor is to try and show it's not just semantics--there are huge differences in how external entities interact with a QMH compared to how they interact with an Actor.  Your comment indicates I didn't do a good enough job communicating that message.  Either I didn't explain it well enough or you have a different idea about what a QMH *is* than I do.

I didn't attend. But I watched the vid.

The QMH was confusing to me. I don't see any difference personally between an actor "Do" and QMH as I don't think there is one and it seemed that you were not really convinced there was one either I do however see a huge difference between Actors,QMH and Queued State Machines (and you mentioned the JKI QSM as in reference to QMHs) and in that context I agree with many of the things you often espouse. The usual example I give for QSMs is reading a file, since it is a lot of code and a lot of messages all to do something that can be done in a single simple VI and there is little benefit in splitting out the states. That VI would then be put in a QMH or Actor.

In terms of presentation skills. The only thought I had was something I was taught which is that it's not productive to read verbatim what is on the slides. The audience will do that. It only eats time and doesn't purvey any more information.

 

........later....

Nope. I do know the difference between a QMH and Actor and I don't think it's semantics. QMHs don't contain state and the state is driven by the producer. If they do maintain state, then they are QSMs (QSMs and Actors being subsets of QMHs). So an Actor can be the same as a QSM if it does not manage it's state (unusual) but a comparison between Actors and QSMs would have been clearer.

Edited August 11, 2013 by ShaunR

[todd]

Just watched the video, Dave. I liked it! It is a good summary of the terms and thought processes that you and others have discussed here on Lava over time. It made me feel good to be able to understand what you were talking about. As for improvement, I agree with Neil that examples would do a lot of good for spreading around "proper" AOD.

 

Thank you for allowing the talk to be published. I'm a bit oblivious to the job-security aspect of "Never tell everything you know." I'd rather work myself out of a job by doing it well or by teaching someone else to do it.

[hooovahh]

I wouldn't call "the semantics between an Actor and QMH" a heated topic.  I can get... energetic... when I'm trying to explain the difference to people, but I don't get angry about it.

 

The reason I talk about the differences between a QMH and an Actor is to try and show it's not just semantics--there are huge differences in how external entities interact with a QMH compared to how they interact with an Actor.  Your comment indicates I didn't do a good enough job communicating that message.  Either I didn't explain it well enough or you have a different idea about what a QMH *is* than I do.

This is very well possible (that I don't fully understand).  If what you are saying is true then maybe the real reason I have a difficulty knowing the difference is I've never used a QMH the way you describe.  Sometimes I start with a QMH template, but by the end I have what you described as an Actor.  So I guess what I'm saying is I'm not sure I've ever used a QMH in an application, only an Actor.

[drjdpowell]

Thoughts on just watching it:

1) More pictures; fewer words.

2) I suggest starting with the Message-Handling Loop or QMH (that people will be familiar with) and talk about what restrictions would make this an Actor: 

     — communicates with other code/actors ONLY via messages to this SINGLE loop.   No by-ref data sharing or other communication methods.

     — no global addressing (eg.  no “named” queues)

3) mention “high cohesion and loose coupling”; an actor is a cohesive unit that is loosely coupled to other actors.  

[Daklu]

........later....

Nope. I do know the difference between a QMH and Actor and I don't think it's semantics. QMHs don't contain state and the state is driven by the producer. If they do maintain state, then they are QSMs (QSMs and Actors being subsets of QMHs). So an Actor can be the same as a QSM if it does not manage it's state (unusual) but a comparison between Actors and QSMs would have been clearer.

 

I spun off a new thread to discuss this.

[Daklu]

Again, thanks for the feedback.  I really do appreciate it.  Please don't interpret my responses below (or lack of response to your comment) as dismissive.  They are just explanations of my thinking. 

 

 

Dave, I thought you conveyed the core concepts of AOD well, but perhaps your talk could have benefited from more fleshed out examples of how you would actually implement your kind of actor in LabVIEW, including how you manage the state data and how a hierarchy of actors would look (in a single VI and perhaps as multiple VIs).

As for improvement, I agree with Neil that examples would do a lot of good for spreading around "proper" AOD.

 

The biggest problem with showing example code is people fixate on the implementation details instead of the principles being taught.  I see that happen everywhere--complaints about the examples in LV, questions asked in sessions and on the forums, etc.  There are lots of ways to implement actors, transports, and messages, and any example implementation is going to reflect a large number of unspoken design decisions.  What I show as being suitable in my example may not work at all in another developer's application or work environment.

 

While I was talking about helper loops one person asked if instrument communication should go in a MHL or a helper loop.  My response was, "it depends."  Not a very satisfying response I admit, but it was the truth.  There are too many unknown variables for me to answer that question without sitting down and talking to him about details.  In retrospect, just having him ask it tells me I'm not communicating the important part of the message adequately.

 

I'm actually considering removing the code examples and replacing them with abstract animations similar to the one early on showing the address being passed around.  I am intending to publish a paper on how I implement AOD in LabVIEW, but that is distinctly different from trying to explain AOD principles in general.

 

 

If what you are saying is true then maybe the real reason I have a difficulty knowing the difference is I've never used a QMH the way you describe.

 

I see.  You had the advantage of learning LV while working with more experienced developers who could help you avoid the pitfalls.  My perception is most people learn LV largely on their own.  We relied on trial-and-error and community wisdom to learn.  Unfortunately there are significant limits to that model and several standard practices that have developed over the years are not robust.

 

Part of what makes the QMH so controversial is it has never been well-defined and means something different to everyone.  When you say "QMH," what exactly do you mean?  The template?  The implementation pattern of a dequeue prim and case structure inside a while loop?  My argument is using QMH to refer to the implementation pattern isn't useful.  Describing a component's private implementation as a QMH tells me nothing of value.  Describing a component's public behavior as like a QMH tells me everything I need to know.  (Namely to not use it. )

 

 

Thoughts on just watching it:

1) More pictures; fewer words.

2) I suggest starting with the Message-Handling Loop or QMH (that people will be familiar with) and talk about what restrictions would make this an Actor: 

     — communicates with other code/actors ONLY via messages to this SINGLE loop.   No by-ref data sharing or other communication methods.

     — no global addressing (eg.  no “named” queues)

3) mention “high cohesion and loose coupling”; an actor is a cohesive unit that is loosely coupled to other actors.  

 

1.  Fair point.

2.  I'm actually thinking about breaking it down further than that.  The actor model views actors as the fundamental unit of concurrent computation.  I view the loop as the fundamental unit of concurrent computation.  An actor is a higher level abstraction containing one or more fundamental loops.

2a.  I did mention (or intended to mention) that.  Maybe I didn't emphasize it enough.

2b.  That's an implementation detail and actually not a property of the actor model.  It's a convention I strictly adhere to and I believe it makes code easier to read, but I can't claim it's a necessary part of AOD.

3.  First, any jargon I use needs to be defined, which distracts from my message to some extent.  Second, the amount of coupling between actors depends on the implementation.  AF actors tend to be fairly tightly coupled to each other, but they are still actors.

 

 

I'm a bit oblivious to the job-security aspect of "Never tell everything you know." I'd rather work myself out of a job by doing it well or by teaching someone else to do it.

 

I put that quote in my sig because I thought it was funny.  Believe it or not I don't hold back information I think would benefit other developers in the community.  I believe "a rising tide lifts all boats" holds true, but to be perfectly honest I do sometimes worry about the consequences of teaching my competitors how to be better programmers. 

 

It's one thing to work yourself out of a job when you are dealing with the same people day in and day out.  They can see the value you bring to the business and often will keep you around.  It's another thing entirely to work yourself out of a job by teaching the competition how to do what you do so they can undercut your prices.

[todd]

"The biggest problem with showing example code is people fixate on the implementation details instead of the principles being taught."
"My perception is most people learn LV largely on their own."
"... I do sometimes worry about the consequences of teaching my competitors how to be better programmers."

 

These statements have convinced me to not ask for code. This morning I was thinking, "Well, how will these lone-rider developers learn to manage their breathing on long shots if they're busy shooting snakes from the hip." (Then I had some coffee.) I learned LV on my own (if reading info-labview and lava during 6i counts as alone). Theory was great, but example code was golden. Only after seeing the data flow through the wires did the theory turn into something useful.

 

"I put that quote in my sig because I thought it was funny."

 

It is funny. When I mentioned it earlier, I was whining (on the inside) about Staab not sharing his presentation. He posted a top-level actor launcher, once, that I learned a lot from (read: totally stole). I haven't provided anything to the community, so I'll quit waiting for other people to show me how to code.

 

"Believe it or not I don't hold back information I think would benefit other developers in the community."

 

Lapdog taught me a lot, too (thanks!). Presentations are all about the audience. Talking theory is useful, unless I don't know how to turn it into wires.

[hooovahh]

Part of what makes the QMH so controversial is it has never been well-defined and means something different to everyone.  When you say "QMH," what exactly do you mean?  The template?  The implementation pattern of a dequeue prim and case structure inside a while loop?  My argument is using QMH to refer to the implementation pattern isn't useful.  Describing a component's private implementation as a QMH tells me nothing of value.  Describing a component's public behavior as like a QMH tells me everything I need to know.  (Namely to not use it. )

Again maybe my misunderstanding but I thought it was well defined.  If I ask NI what is a QMH won't they open the template that comes with LabVIEW?  Now I never use that template as it is, I think I always add an event structure in the "" case, add a Default case to handle typo issues, and add a BFC (Big F***ing Cluster) on a shift register.  Is this now no longer called a QMH?  It feels like it is a QMH but it also feels like it is something more specific but it is still a QMH is it not?  

[viSci]

Hi Dave - I thought your presentation was very good.  Unlike many others I have seen you convey a sense of thoughtful composure and confidence in your subject material.

[Daklu]

These statements have convinced me to not ask for code.

 

I don't think asking for code is bad, or wrong.  Code samples are good at showing how to do things.  Theory explains why you do things.  My presentation focused on the theory, so code samples kind of distract from the message.  (FWIW, I'm far less concerned about showing the how than I am about explaining the why.)

 

 

I haven't provided anything to the community...

 

Not true.  You've participated in discussions and posted about your experiences.  And you posted that awesome link to Hewitt's channel 9 video, which did more to help me understand the actor model than anything else I've encountered.

 

 

Talking theory is useful, unless I don't know how to turn it into wires.

 

Good point.  I remember in college how frustrating is was for me when professors lectured at length about some theory before showing any practical application of the theory.  I often wished they would integrate theory and application more tightly.  The question then becomes, how can I show practical application of the theory while avoiding implementation fixation?  I hoped the abstract animations would be sufficient to reinforce the theory.  Maybe they're not?

 

 

 

If I ask NI what is a QMH won't they open the template that comes with LabVIEW?

 

I dunno what they would say (ask 10 people and you'll get 20 different answers), but outside of the JKI-SM I never see a QMH implemented using an array of strings, as shown in the 2012 QMH vi template.  Interestingly, the implementation in the 2012 QMH project template is completely different.  In your opinion, which implementation correctly defines what a QMH is and how do you justify the claim?

 

 

Is this now no longer called a QMH?  It feels like it is a QMH but it also feels like it is something more specific but it is still a QMH is it not?  

 

Depends on whose definition you're using.  According to my definition adding data state and an event structure in one of the cases doesn't change it from a QMH into something else.  For me, the main differentiator between QMH/QSM and well-written MHL* is a QMH/QSM uses implementation techniques that are not generally thread safe--they may be okay in a specific application, but the technique cannot be universally applied. 

 

[*I consider a well-written MHL one that conforms to the actor model.  In general, when I say MHL I mean a message handling loop that conforms to the actor model.  If a loop handles messages and does not conform to the actor model, I call it something else.  Usually "QSM" or "QMH," but if I'm feeling cranky I'll call it a blight on the LV developer community.   In this post I refer to the "template's MHL" a few times.  I do that because it is labelled as a "Message Handling Loop" in the template, even though the loop implementation more closely matches a QMH.]

 

For example, the QMH project template's MHL makes extensive use of enqueuing messages to itself.  Self enqueuing doesn't automatically introduce race conditions, but it sure makes it a lot easier to unknowingly add them.  Figuring out whether or not any specific implementation has detrimental race conditions requires concentrated code inspection.

 

The template's MHL also exposes three messages that shouldn't be public:  Initialize Data, Initialize Panel, and Update Display.  Poor API design makes the template's MHL harder to use than it should be and increases the opportunities for programming errors.

 

You mentioned adding a "" case with an event structure inside it to process user inputs.  I presume you also have a constant wired to the dequeue timeout.  Dequeue timeouts are another technique that works only in certain situations.  (I noticed the dequeue used in the template doesn't have a timeout.  Kudos to whoever wrote the code for recognizing their danger.)

 

As I've said before there's a lot of gray between a QMH and an MHL.  QMHs are often written at the same time as the message sending loop, resulting in two loops that work okay together but are inadequate as independent components.  Developers write a QMH based on their knowledge of the message sending loop.  A new, arbitrary message sending loop frequently causes unpredictable or unintended responses in the QMH.  Conversely, an MHL is written without specific knowledge of the sender.  The MHL developer accepts he is unable to control the order or frequency of messages received and writes the MHL code to deal with those situations.

 

I suspect a QMH could be used as a private helper loop to a MHL, though I wouldn't because correct QMH behavior is harder to verify than other techniques.  QMHs are entirely inadequate to use as the public interface to other components in a concurrent application.

[drjdpowell]

Rather than argue the difference between a queued message handler (built from from loop) and a message-handling loop (sitting behind a queue), would it be better to focus on the difference between a message queue with only a single enqueuing process, versus one with multiple writers in parallel that could lead to race conditions?

[hooovahh]

I dunno what they would say (ask 10 people and you'll get 20 different answers), but outside of the JKI-SM I never see a QMH implemented using an array of strings, as shown in the 2012 QMH vi template.  Interestingly, the implementation in the 2012 QMH project template is completely different.  In your opinion, which implementation correctly defines what a QMH is and how do you justify the claim?

I didn't realize there was a new QMH in 2012.  You can still find the old (which is the one I was referring to) under File >> New... Templates.  The Project template for a QMH in 2012 is quite different and I have a whole new set of feelings towards.  Before 2012 I didn't think there would be a question on what is a QMH because NI had a template on it, and JKI had a template on it that both used an array of string.  So having these two be the only two examples I've seen I assumed that's what made it a QMH.  An array of states (in this case string) to be processed one at a time by going to the respective state.  Adding user events, and shift register data still kept it a QMH in my mind so all discussions of QMH I've had were with this very open state machine like pattern.

 

You mentioned adding a "" case with an event structure inside it to process user inputs.  I presume you also have a constant wired to the dequeue timeout.  

You would be wrong.  Generally I have a -1 timeout.  I use User Events as my messaging structure and I don't have timeouts unless I see a need for them to actually poll something periodically.  But even that can be handled by sending a message periodically instead.

[ShaunR]

Rather than argue the difference between a queued message handler (built from from loop) and a message-handling loop (sitting behind a queue), would it be better to focus on the difference between a message queue with only a single enqueuing process, versus one with multiple writers in parallel that could lead to race conditions?

Indeed. In the sense of an ordered list of messages and "how" it is realised (queue primitive or while loop with shift register) is, IMO, irrelevant (thanks for spelling out MHL->Message Handling Loop. Maybe I can make up the acronym OLOM Lets see if it catches on )

A message handler, handles messages. Period. A queued message handler buffers the messages before it handles them. That's really all there is to it.

Edited August 13, 2013 by ShaunR

[Daklu]

Indeed. In the sense of an ordered list of messages and "how" it is realised (queue primitive or while loop with shift register) is, IMO, irrelevant

 

I agree, but you can see from the responses there isn't a universal consensus on it.

 

[Edit - The remainder of my response can be found here.]

[jcarmody]

I just finished watching the presentation and was pleased that I understood what you were saying.  I'm neither advanced nor an architect (as in "LAVA"), but I lurk around here, and I thought I'd add a CLD's opinion.

 

After seeing the presentation I am more confident that I can develop an Actor Oriented Design for a project I have in mind but, as has been said before, I'd like to have some code to study.  It wasn't needed in the presentation, but a slide at the end with a link to example code would be nice.  Someone might suggest that I look at the Actor Framework project templates that ship with LabVIEW... I'd suggest that I can't understand them as well as I could your four-loop, multiple-monitor example from the presentation.

 

Kudos and thanks for sharing!

 

Jim

[Daklu]

Thanks for the feedback Jim.  Code samples are a tricky problem I haven't figured out how to address yet.  It's not like any of the implementation is particularly complex or elegant.  It's all just very straightforward LV code, minus those implementation practices that lead to trouble.

 

To everyone who has suggested sample code would be helpful, assuming there was sample code available...

 

1. Which best describes your reason for looking at the sample code?

a. To better understand the theory.

b. To figure out how to implement the actor model.

 

2. What are the top two things you understand least and want to examine in the sample code?

a. Actors in general

b. Transports in general

c. Messages in general

d. Message handling loops

e. Helper loops

f.  Interactions between loops

g. Other? (Specify)

 

3. What other information or knowledge would you hope to gain, or questions would you hope to answer, by examining sample code?

[jcarmody]

I've been struggling with getting started in AOD and I think back to my early days of learning LabVIEW, then even earlier to when I took a stab at Java.

 

First, Java...  I wanted to write a program that would descipher our products' "intelligent" part numbers and build a BOM from a database of parts and rules that I'd fill based on assembly drawings.  My first attempt had one main() method that was several pages long that did everything in the same manner my BASIC programs would have done them.  I took a Java class at a community college shortly after and a light bulb turned on and my BOM program became a bunch of neat little objects creating arrays of other neat little objects that all did their own things as neatly as you'd please.  That course I took made all the difference in the world.

 

Now, LabVIEW...  I left one job to work for an Alliance member company and started on a Monday.  By Wednesday I was wondering if I hadn't made a horrible mistake because I was struggling with my first LabVIEW assignment.  Anyway, I eventually managed to "understand" State Machines and I built a

controlling an automated assembly process.  You should see the code!   Anyway, I continued working with what I thought I knew and was completely floored when the JKI State Machine template was released to the world a few years later.  I remember commenting that I was surprised that the company that "taught" me LabVIEW didn't have a State Machine template to use and I still cringe whenever I have to support some of the older stuff I wrote.  I learned a lot seeing and discussing that framework.  That made a huge impact on my productivity and performance as a LabVIEW developer.

 

Finally, Actors.  I'm confident that I could develop my own interpretation of an Actor Framework that would "work", but I'm worried that I'd make a lot of mistakes similar to those I made learning State Machines.  Without a semester-long class (like my Java experience) or a ready-made template (à la the JKI SM), I'm not confident that I'd become proficient any time soon.  And even then, I'd have to support production software developed while learning the hard way.

 

Answers:

1) b

2) b, c, g (command pattern)

3) I would hope to be able to be able to begin an actor-oriented project shortly after.

[John Lokanis]

I don't think asking for code is bad, or wrong.  Code samples are good at showing how to do things.  Theory explains why you do things.  My presentation focused on the theory, so code samples kind of distract from the message.  (FWIW, I'm far less concerned about showing the how than I am about explaining the why.)

 

How about creating examples of how to use Actors to solve common programming challenges or implement different architectures without using LV code?  Instead use pseudo-code or maybe simple block diagrams to illustrate what actors and messages would be created to implement the solution.  You should also include some diagrams that shows both how the parts interact and how they are (or are not) coupled together.

No need for LabVIEW code since your discussion is about theory and not G programming tips and tricks.  If you can give your presentation to a Java or C++ programmer and they understand it, you have done your job.

[Daklu]

How about creating examples of how to use Actors to solve common programming challenges or implement different architectures without using LV code?

 

The metronome and job processor examples were my attempt to show solutions to common challenges.  Granted, they are LV code instead of abstract animations... (What can I say, it takes a long time to create complex animations in powerpoint.)

 

As far as common programming challenges, integrating continuous processes, periodic processes, and/or sequencers into an application are the three things that come to my mind.  What other kinds of challenges would you like to see implemented?  (I don't think there's any point in showing how to implement different architectures.  Once you understand how to integrate concurrent processes safely implementing an architecture isn't difficult.)

 

I've been considering reimplementing the AF swamp cooler example using my style of AOP (which I self-righteously dub, "Agile Actors.")  Would that be helpful?  I've mentioned many times writing takes me a looooong time.  If I write the code would someone else be willing to take the lead on doing a write up for it?

[todd]

Theory and simple example code complement each other. Maybe one way to go is to show a simple implementation of a particular concept in each AOP style: AF, AA, QSMLH (queued-state message-loop handler).

 

As to the multiple choice question: all of the above.

 

Actually:

 

2.a+e: A few simple sample actors, where each one has a different type of helper loop: no loop, self-messaged loop, free-running (timeout) loop, etc.

2.c+d+b: A few simple message types: raw-queue producer-consumer (data only), queued message (command + data), AF message. MAYBE self-addressed messages: pass a notifier with the queued element, etc.

 

Have I used the word "simple" enough?   Keeping the code simple makes it easy to understand quickly. Then, switching between the different methods allows the theory to stay in my mind. After seeing Jack D's events presentation, I understand why people were saying such good things about him. He showed many ways to make things happen, and they were all simple. The cooler example is too involved to quickly understand - the theory would get lost under the wires (unless one already knows AF, in which case simple code can teach the theory just as well as more complex code).

 

If you want, I'd be happy to code up some simple AF examples that correspond to the functionality of some AA examples (maybe AgAc, instead?). Plenty of people can do it better than me, but I can handle simple!