How would you explain actors to a non-programmer? [closed]

Question

Well, the title's pretty much it: if I sat a non-techie/my mum/twelve-year old boy/cocker spaniel in front of you and asked you to explain actors to them, where would you start? I ask because my master's project involves them to a pretty large degree, and every other day someone asks me to tell them what I'm doing. When I'm talking to other people on my course it's not so bad—usually the concept is foreign but understandable—but recently my flatmate, a chemist, asked me to explain it to her, and to say I struggled would be a pretty humongous understatement.

I'm looking for some sort of explanation that conveys the idea, rather than the technical underpinnings. It can be a metaphor, and it doesn't have to be precise—I just want to make them understand what I'm doing with them. Any ideas?

Obelia

Do people vote to close as "not a real question" simply because they can't immediately think of an answer? – Limbourg

Why do I feel like I am doing your master's project? – Coacervate

Heh… I'm fairly sure you're not, Joe. My project is to write a framework that uses actors to create modular processes running on both the client and the server, as well as a number of test cases. I have a hard time explaining technical things in a non-technical way—that's why I asked this question. – Obelia

This question appears to be off-topic because it is not within the bounds of discussion as described in the help center. – Vilmavim

Answer 1

• There can be many actors. All actors act "at the same time". The concurrency is a key part of this model.

• Actors cannot know what other Actors are thinking. The only way to move information is with a message. (no shared state)

• Actors can receive messages, and act on them by:

  • doing computation with the data in them

  • sending messages to other actors

  • creating other actors.

  • ignoring/discarding the message.

This basically makes actors just like... People. People don't know what each other are thinking, they must send messages to convey information, they have the choice of ignoring incoming messages, considering them, or communicating with other people. Random bad things can happen to people. Lots of people all do things at the same time. To handle more load, add more people.

Regarding your masters project, I suggest finding out about the Erlang Web framework. The programming language Erlang is based on the Actor model, and is used to great effect in scalable systems including phone switches... and the Facebook messaging system.

Coacervate

This is pretty much exactly what I was looking for. Brilliant. Regarding Erlang: I did some research into it and it looks great. However, the framework I'm writing is meant to make it easier to use actors on the web, and learning a new language is a bit much for most people, so I went with Python and have built my own classes that behave like actors. I'm tempted to port it in the future though. – Obelia

This is like saying "I heard threads were great... so we need to port threads to the web!"... well the web browser can ALREADY be considered an actor... it sends a message, doesn't share state with the server, waits pending reception of another message, and does computation on it. – Coacervate

Erlang takes actors "all the way down" .... and supports millions of concurrent actors (called processes) on a node, and transparently scales to multiple nodes while handling all the communication automatically. It's nice to have these kind of "roots" when you're really trying to take on a large concurrent task. – Coacervate

The web browser absolutely shares characteristics with actors. What I want to do is create an environment which allows for users to create extensions to websites that can easily interface with the rest of the site, on both the client and the server. What I want is lots of tiny little processes that do one thing, and I want the user to be able to switch them on and off. I don't need the fault tolerance and scalability of Erlang—I need actors that work in JavaScript as well as on the server. I definitely need to read more about Erlang though—I think I could learn a lot from playing with it. – Obelia

Answer 2

I'll try a simple metaphor:

Actors are people doing some work inside their houses. In front of each house, there is a mailbox. In order to communicate with each other and get work done, messages are sent between the actors.

Exaggerate

This is basically exactly the model ToonTalk uses for concurrency. Except that you dispatch a "bird" instead of mailling a letter. toontalk.com/English/concur.htm – Coacervate

Answer 3

I am not sure that this will be good one, but I'll try:

Let's imagine a classic middle-east marketplace. There are buyers(suppose they are just walking tourists) and sellers. Buyers are walking through marketplace, and sellers cry out name's of theirs goods: Carpets!! Species!!! Horses!!! Сandies!!! Jewels!!! and so on... Some buyers are not interest in specific kind of goods and go to the next store, but some buyers become interested, and ask: "How much is it?", seller: "50$", buyer:"Can you give me a discount?", and so on...

Actors are buyers and sellers here. Sellers are sending messages with types of their goods. Buyer can skip a message, or can send message for asking price.

Sacrum

Answer 4

Actor - is something we can also call subject. Actors are doing something with objects. Actor is calls so, because it's somebody who acts.

Herschelherself

Answer 5

I would say, "Actors are a simple way to tell computers to do more than one thing at the same time. They are different from other ways to tell computers to do more than one at the same time because they take fewer resources than some of the alternatives and because they are easier for programmers to use correctly than some of the other alternatives."

Ensconce

If my audience actually wants to know how actors work, then I would go with the example of people in different houses who only talk to each other by putting letters in mailboxes, as @Exaggerate already suggested. However, most of the time, I don't think my wife/mother/neighbor/whoever actually wants that much detail. ;-) – Ensconce