Coding Adventure: Karma as a System

KaaS

Karma-as-a-System is a computer program that emulates the mechanisms of Karma.

Wikipedia — Karma is a concept of action, work or deed, and its effect or consequences.[1] In Indian religions, the term more specifically refers to a principle of cause and effect, often descriptively called the principle of karma, wherein intent and actions of an individual (cause) influence the future of that individual (effect):[2] Good intent and good deeds contribute to good karma and happier rebirths, while bad intent and bad deeds contribute to bad karma and bad rebirths.

Let's design KaaS. Imagine you're taking a cyber philosophy class - what are you submitting for this?

I'll start by transforming the given Wikipedia quote into a vocabulary about computer systems, to get a sense of what we'll be building.

1. Karma describes processes and their outputs.
   "Karma is a concept of action, work or deed, and its effect or consequences." — Wikipedia

2. A system's state+outputs influence its future state.
   "Indian religions, the term more specifically refers to ... the principle of karma, wherein intent and actions of an individual (cause) influence the future of that individual (effect)" — Wikipedia

3. A system's state+outputs influence its future inputs.
   I've substituted "state" with "inputs" because a computer system's state is always a function of its input. Runtime state is computed from user inputs, and compile-time state (or "hard-coded state") is determined by developer inputs. Importantly, every state change comes from an associated input.

4. Qualities of a system's output influence the qualities of its inputs.
   "Good intent and good deeds contribute to good karma ..., while bad intent and bad deeds contribute to bad karma..." — Wikipedia

Putting this all together, let's define the system we want to build once and for all.

Let's implement this system as a Graph of nodes and lines, where lines transport information ("state") between nodes.

// TypeScript

type Node = { /* ... */ };
type Line = [Node, Node];

type Graph = { nodes: Set<Node>, lines: Set<Line> }

/**
 * This function defines the mechanism
 * by which nodes send+receive information.
 *
 * Some might prefer for Node to have object-oriented
 * send() & receive() methods. I prefer functional style.
 */
function transmit([left, right]: Line) => void {
    // "right" receives information through "c"
    //    ^
    //    |  "left" emits information through "a" and "b"
    //    |        ^        ^
    //    |        |        |
    right.c = left.a + left.b;
};

To become karmic, nodes emitting information through lines will eventually have their outputs returned to them as inputs. This must abstract excellently across different kinds of information. Ex:

• After sending some object O with functional properties P, one should expect to eventually receive some object(s) qualitatively similar to O, or with properties functionally similar to P.

• Increasing|decreasing the frequency of similar outputs will eventually affect the input frequency of qualitatively similar inputs.

Let us define some things.

Eventually?

An event E happens 'eventually' if other events are permitted to happen first.

Let's model this in transmit as an asynchronous function.

async function transmit(...) { /* same as before */ }

Qualitatively similar?

Personal experience strongly determines how you interpret this.

Simple examples:

• Red is qualitatively similar to maroon
• Oranges are qualitatively similar to clementines

Hard examples:

• An ant is qualitatively similar to a pebble (think: size)
• An ant is qualitatively dissimilar to a pebble (think: alive/dead)

Controversial examples:

• Pornography is qualitatively similar to a cigarette
• The color gray is qualitatively similar to unseasoned food

Do you disagree with these? Can you think of more?

In KaaS, we expect qualities (...whatever that means) to eventually return to the system that caused them. But clearly, qualities can be perspective-dependent! What even is a quality? We still have not answered that question.

This is a challenging problem, because in order to proceed with our implementation of KaaS, we need a way to define:

1. What a quality is
2. What a perspective is
3. What a perceived quality is
4. ... and so on.

Well guess what? Not a problem :) programming languages are cool, man, and I'd like to show you how.

Let's define a function to represent a system of inputs and outputs.

function system<I, O>(input: I) => O {
    // <scope>
    let output = input.foo + input.bar;
    return output as O;
    // </scope>
}

The perspective of the system is, literally, the scope of the function.

The perceived qualities of the system's inputs and outputs are, literally, whatever information it can access within that scope.

Feels like magic, right? We've hardly even done any real coding, yet we have all the definitions we need to proceed with developing KaaS.

Sorry :( This is where I ran out of steam. The purpose of this post isn't to actually design a system (spoiler alert!) - it's really just to make you think.

Questions:

As you've grown spiritually, did it evolve your perspectives on how systems interact? Further, what did you notice about your new mental models in your professional life?

If you have a computer science brain, and are interested in spirituality, then it's important for you to recognize the mechanical overlap between the two disciplines.

:~)