Picos and the Actor Model of Programming

Picos are persistent compute objects. Persistence is a core feature that distinguishes picos from other programming models. Picos exhibit persistence in three ways:

Persistent identity—Picos exist, with a single identity, continuously from the moment of their creation until they are destroyed.
Persistent state—Picos have persistent state that programs running in the pico can see and alter. The state is is isolated and only available inside the pico.
Persistent availability—Once a pico is created, it is always on and ready to process queries and events.

Persistent identity, state, and availability make picos ideal for modeling entities of all sorts. Applications are formed from cooperating networks of picos, creating systems that better match programmer's mental models. Picos employ the actor model abstraction for distributed computation. The Actor model treats an actor as the universal primitive of concurrent computation. Each pico is an independent actor. Specifically, in response to a received message, a pico may

send messages to other picos—Picos respond to events and queries by running rules. Depending on the rules installed, a pico may raise events for itself or other picos.
create other picos—Picos can create child picos and delete them.
change its internal state (which can affect its behavior when the next message is received)—Each pico has a set of persistent variables that can only be affected by rules that run in response to events and cannot be inspected from outside the pico.

In addition to the parent-child hierarchy, picos can be arranged in a heterachical network for peer-to-peer communication and computation. A cooperating network of picos reacts to messages, changes state, and sends messages. Picos have an internal event bus for distributing those messages to rules installed in the pico. Rules in the pico are selected to run based on declarative event expressions. The pico matches events on the bus with event scenarios declared in each rule's event expressions. Any rule whose event expression matches is scheduled for execution. Executing rules may raise additional events. More detail about the event loop and pico execution model are available elsewhere.

Why Picos

You will use picos to complete the labs for this course. I believe that the actor model is the best way to learn about distributed and decentralized systems because it saves you from many of the pitfalls that beset this kind of programming and lets you focus on the primary concepts we're trying to learn. Like any good programming system, picos provide convenient abstractions that save you from having to get down in the weeds.

A few of you will like picos. Many of you will hate them or, at best, tolerate them. Remember a few things:

What you learn transcends a particular language or programming system.
There's nothing wrong with asking you to use a non-traditional system in class. That's what education is all about.
While you may have a hard time believing it, you'd be just as uncomfortable, maybe more, in a language you're familiar with that's unsuited to the task.
Picos allow you to create systems of processes that interact with each other asynchronously (i.e. a distributed system). Managing multiple processes and dealing with asynchrony is likely the source of much of your discomfort. And that's why you're here: to learn about distributed systems.

The first five labs will introduce you to picos, orthogonal persistence, and event-based messaging. The final five labs will guide you in developing systems of picos (processes) that interact with each other to accomplish specific tasks despite being distributed and asynchronous.

Beyond learning about distributed systems, I also believe picos are the best way to build distributed systems.

Events and Rules

Picos are programmed in a language called KRL. Picos contain KRL rulesets that determine their behavior. Rulesets contain rules and functions. A pico can respond to a query by executing a function or reacting to an event. A query is answered by executing exactly on function. A single event may cause multiple rules to fire. Thus each pico presents a unique event-query API.

Event-query model for a pico.

This is an example of a simple ruleset:

ruleset hello_world {
  meta {
    name "Hello World"
    description <<
A first ruleset for the Quickstart
>>
    author "Phil Windley"
    shares hello
  }
   
  global {
    hello = function(obj) {
      msg = "Hello " + obj;
      msg
    }
  }
   
  rule hello_world {
    select when echo hello
    send_directive("say", {"something": "Hello World"})
  }  
}

This ruleset has a meta section that contains descriptive information about the ruleset, a global block that contains a single function definition called hello, and a rule called hello_world. When installed in a pico, that pico would respond to a query called hello or react to echo:hello events. You will learn much more about rulesets and how they work in the lessons.

Documentation

The documentation for picos is extensive and comprehensive. Like any experimental system, however there will be places it is out of date. Here are a few things to pay special attention to:

Please be sure to let us know if you find an issue with the documentation that needs to be corrected.

Pico Engine

Picos execute on a server called the pico engine. The pico engine is open source. The current pico engine is third generation and represents over 13 years of effort. The pico engine runs on top of Node.js. You can run the pico engine on your laptop, AWS, or any other computer that can run Node.

Tour

The Quickstart and this video will give you a tour of the pico engine and get you started using it.