DEV Community: Seth T.T

Tech Story: C++ compiler behavior in a technical interview

Seth T.T — Sat, 14 Dec 2024 23:15:47 +0000

Interviewer: Given this example C++ function which assigns a local vector a into another local vector b then return b, would the compiler optimize the copy (a -> b) into a move?

My Response

I can't tell you the answer, because I don't know. But I can tell you how I would figure it out resourcefully, and we can talk about the effectiveness of my approach.

Here, we're dealing with copies into returned local values, and asking whether the compiler would optimize the copy into a move.

Gut feelings

Automatically, my brain is going to pull memories from past programming experience and consumed media which may be relevant to the example. Any information relevant to answering the problem will be used to make a "gut prediction," which provides two outputs:

(A) an expected outcome (yes, the optimization happens)
(B) my confidence in the prediction (not confident at all xD)

After a couple of seconds, my brain will retro-fit an explanation onto those two data points, and that is when the "slow thinking" brain can analyze my prediction and make decisions. Here are the explanations my brain generated:

(A) Yes, the optimization happens because I've seen the C++ term "Return Value Optimization" thrown around various forums, and that seems relevant to the problem. I also don't remember seeing examples of using std::move in return statements, so I lack reasons to think the answer is actually "no."
(B) My understanding of C++ has a lot of "unknown unknowns" r.e. its complex language semantics and optimization rules. I know that otherwise-trivial structs and classes do become non-trivial if any of their instance variables are non-trivial. This makes struct triviality a "viral" data property that can butterfly-effect how the compiler might optimize a piece of code. I don't know if other "viral properties" exist which can also change compiler behavior, and without knowing that it becomes impossible to reason about how the compiler will behave. So, my brain throws its squishy hands in the air and says "impossible to predict."

Basically, I don't make any assumptions about C++ because I know better. So... how do I figure out the answer?

Use Resources

Step 1: Google. Always. Starting with what I know, I'd probably google "return value optimization" + "move semantics" as a query to find literature that relates those two topics. Stack Overflow is a moderated source-of-truth for popular questions, and might have a good answer if the question is popular enough to have received moderator attention.

But let's assume Stack Overflow is down for maintenance or my internet is disconnected and I can't Google the answer. How would I figure this out? Simple: compare the assembly.

Analyze Evidence

Step 2: I would compile the example program using zero optimization (-O0) and full optimization (-O3) and make the compiler emit assembly code (-S) instead of an executable. Comparing the assembly side-by-side, we can evaluate any code differences and make a prediction about whether the copy was optimized into a move. I say 'prediction' and not 'answer' in case the assembly is difficult to interpret or in case other optimizations are occluding the evidence we're looking for.

Learn the Rules

But this still only gives us the answer in this particular case. If we change the code, or look at an example of a real production codebase, the answer might not be the same, and unless we know exactly what rules the compiler follows to optimize copies, you'll always have to re-compile the code and evaluate the assembly to know for sure the optimization happened.

That's where my brain goes. Cheers!

On Commercial Software Evolution

Seth T.T — Thu, 10 Oct 2024 03:32:53 +0000

Cover image by Wikimedia Commons.

This article models the free market using Stuart Kauffman's Fitness Landscape to understand its influence upon, and from, commercial software products.

Bolded vocabulary terms are used across article sections.

Fitness Landscape

From Wikipedia:

In evolutionary biology, fitness landscapes or adaptive landscapes (types of evolutionary landscapes) are used to visualize the relationship between genotypes and reproductive success.

A few key points:

a genotype is a collection of features intrinsic to some individual or population.
reproductive success can be generalized as fitness value.

Here's an example of a fitness landscape visualization:

In this example, the 2D horizontal axes represent the genotype, and the 1D vertical axis represents the fitness value. In reality, the genotype may be more than 2 dimensions. It may be useful to imagine the genotype as an N-dimensional collection of various qualities.

From Wikipedia:

Genotypes which are similar are said to be "close" to each other, while those that are very different are "far" from each other.

This helps us compare different genotypes across the landscape.

Dynamic Structure

Ann evolution function defines the fitness value for every distinct genotype.

Here's one example of an evolution function moving and resizing the hills on a fitness landscape:

A few observations:

The evolution function doesn't introduce any "cliffs" or "holes" in the fitness landscape.
The evolution function is perpetual, and does not stop at any time.

We also see a collection of distinct gray species on the landscape's surface.

Each species corresponds with some unique genotype at any point in time.
Each species can move across the landscape by changing its genotype.

From now on, the landscape function is the evolution function that changes the surface of the fitness landscape, and the species function is the evolution function that moves species across the surface of the landscape.

The Commercial Software Market

The below translation is generally a gross over-simplification, but for the purposes of this article, it'll do just fine.

Fitness Landscape	Commercial Software Market
Species	Software product
Genotypes	Features
Fitness value	Feature/product value
Species function	Producer behavior
Landscape function	Consumer behavior

⬆️ You can ignore this table, it's just for reference.

Some key points:

A software product is a collection of features
Consumer behavior affects feature value, and transitively, product value

As with evolutionary biology, producers must evolve their software products to stay in business, or else they die. The ability of a producer to evolve their products over time is more necessary to their long-term survival than having maximally-valuable products.

For this reason, it's important for producers to have some control over their species function so they can remain in business.

Fun fact: some producers are able to routinely ship poor-quality software products, because their species function is just adaptive enough to keep them alive.

Since we're modeling producer and consumer behavior using evolution functions, we can explore the mathematical structure of these functions to better understand the market.

Producers and Consumers

Consumer demand evolves smoothly and continuously over time. Software, however, is shipped and released on a discrete time schedule. Consumers perceive spontaneous "jumps" as new features are introduced or removed from a software product.

Producers dislike this asymmetry, because a set of features under development may become less valuable by the time they are released. When producers cannot react quickly or regularly to consumers, the landscape function has outpaced the species function.

This is evident from the growing popularity of Agile Software Development, a methodology for producers to accelerate their species function and keep pace with the consumer landscape.

Agile Software Development

The four main principles of Agile, according to Wikipedia:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

The critical point is responding to change. Agile places a great emphasis on

detecting change in the fitness landscape
nudging your genotype towards areas with a higher fitness

In effect, Agile allows producers to be more confident that whatever features they ship will be in demand by the time they are released.

While this is generally effective, there are some interesting costs associated with having a higher-pace evolution function.

Technical Debt

This section is subjective.

For software, it is faster and easier to expand an existing product, than to build a new one entirely. Producers are generally suspicious of building new products in existing high-fitness areas, and will prefer to push an existing software product towards locally-fit areas whenever possible.

Even when expanding to new consumer markets (new "hills" on the fitness landscape), a producer will opt to Frankenstein-surgery their existing software onto that hill, and will only create a new product if absolutely necessary.

What happens is the species function slows as the number of features becomes larger. The high-paced species function that once benefited our species has since become cancerous, chaining the software product's ability to evolve with consumer demand.

Companies experience this as technical debt, and it's generally difficult to solve because of how immensely complex their software has become.

A Solution

If you've made it this far, thank you.

I believe, but am not certain, there is no "golden pace" for software development to avoid technical debt. I believe that every commercial software product will encounter it in some form, by virtue of the discrete evolution function.

I believe, but am not certain, that we can develop software without technical debt. And for as long as I strive to build better software, I will continue to believe that.

From Sofia Konobievska: How to Sell Technical Debt from a DevOps Perspective?.

Thank you for reading, and enjoy your next day.

vcpkg - how to modify dependencies

Seth T.T — Fri, 27 Sep 2024 18:17:56 +0000

Purpose

This tutorial is made for existing projects that use vcpkg to manage their C++ dependencies.

Sometimes, it becomes necessary to modify some elements of a C++ library that your project depends on. Modifications can include:

Changing compilation flags
Changing installation strategies
Changing source code
Changing static data

This tutorial demonstrates how to apply these changes to a dependency installed with vcpkg in a way that's cheap, shareable, and permanent.

The full process can be completed in 15 minutes.

Project Structure

We'll use a mock project structure, like so:

project/
 |-- include/
 |-- src/
 |-- vcpkg/
 |-- CMakeLists.txt
 |-- README.md

In this example, we'd likely set up the vcpkg CLI utility, like so:

# pwd: at project root
chmod +x ./vcpkg/bootstrap-vcpkg.sh
./vcpkg/bootstrap-vcpkg.sh

Step (1 of 4): Create a Local Registry

The first change we'll make to the project structure is making a directory to hold our vcpkg portfiles.

A Port is a small, cheap collection of metadata files which instruct vcpkg on how to download, configure, build, and install your dependencies.

To customize our dependency, we're going to copy its portfiles and place them in our own custom registry.

First, let's create a directory to hold our vcpkg portfiles:

# pwd: at project root
mkdir registry

Call it whatever you'd like. This tutorial refers to it as a local registry.

Step (2 of 4): Copy the Port Files

This tutorial will use the fake "foobaz" package as an example.

# pwd: at project root
./vcpkg/vcpkg install foobaz

We're going to copy the foobaz portfiles into our local registry in order to apply our modifications in the future.

# pwd: at project root
cp -r ./vcpkg/ports/foobaz ./registry/foobaz

Take a look inside ./registry/foobaz and you'll probably see three files:

project/
 |-- registry/
 |    |-- foobaz/
 |    |    |-- build_fixes.patch
 |    |    |-- portfile.cmake
 |    |    |-- vcpkg.json

Let's examine each of them.

build_fixes.patch is a git diff that vcpkg applies to your dependency's source tree before compiling and installing it.
portfile.cmake is a cmake script that tells vcpkg where to find your dependency's source tree, plus some other stuff.
vcpkg.json is a metadata file that's conceptually similar to a package.json file from the Node.js universe.

It's recommended to keep vcpkg.json the same.

This tutorial is going to demonstrate how to generate a new build_fixes.patch file, and it will contain the modifications you want to apply to the source code, build configuration, etc.

Please note that portfile.cmake is run in CMake's script mode, so we cannot use this to change build parameters for our dependency. Those must be modified from within the build_fixes.patch instead.

Step (3 of 4): Generating a Patch File

Awesome, it's time to make some changes!

First, clone the dependency's source tree, so we can make our changes. This is a temporary folder that won't be checked into your git project. I'm cloning inside of registry/foobaz for convenience, but you may put it anywhere you'd like.

# pwd: at project/registry/foobaz
git clone https://github.com/username/foobaz.git source

Next, we're going to apply the existing build_fixes.patch file on top of the source tree. This puts our dependency's source into the state that vcpkg uses by default when you install it.

# pwd: at project/registry/foobaz/source
git apply ../build_fixes.patch

Now, it's time to make your changes! You can modify the CMakeLists.txt to adjust build configuration, comment out source files, introduce new code, whatever the hell you want.

After applying your modifications, create a new git diff file. This overwrites the existing build_fixes.patch with the changes you've just made (plus whatever was already there).

# pwd: at project/registry/foobaz/source
git diff > ../build_fixes.patch

Remove the source tree when you're done.

# pwd: at project/registry/foobaz
rm -rf source

Finale (4 of 4): Use your Modified Dependency

It is necessary to remove foobaz from vcpkg so that we can re-install our modified version.

# pwd: at project/
./vcpkg/vcpkg remove foobaz

From now on, to make vcpkg download your modified dependency, the CLI tool must be invoked like so:

# pwd: at project/
./vcpkg/vcpkg install foobaz --overlay-ports=registry/foobaz

Check it out! You're done! 🎈

Find me on github

My Struggle Learning Set Theory as a Programmer

Seth T.T — Thu, 07 Dec 2023 06:31:33 +0000

Cover image from Wikimedia Commons

I'm Seth, an undergrad student with an established background in computer science.

This article introduces the bare fundamentals of set theory, then compares mathematical sets with some common data structures and type systems found in computer science.

Sets

Paraphrasing Wikipedia,

A set is a collection of different things,

and

A set contains elements which can be information of any kind: numbers, shapes, people, ...

Okay, my bedroom is a collection of laundry and furniture, so Room = {laptop charger, old sock, soft bed}.

Next,

Sets are uniquely characterized by their elements. Two sets that have precisely the same elements are equal.

This implies that any set containing exactly {laptop charger, old sock, soft bed} is literally my room.

This took me a while to understand! Last thing,

Given two sets, X is a subset of Y if every element of X is also an element of Y.

So, for example, the set X = {1, 3} is a subset of Y = {1, 2, 3} because Y contains every element of X.

Now, let's see how pure mathematical sets compare with real-world computer data structures.

Data Structures

Here's a few data structures that built my preconceptions about mathematical sets:

Array<T>
Set<T>

Being familiar with these data structures helped me tremendously while learning set theory, but later came to hinder me in some interesting ways.

Computers are bound to certain time- and space- constraints that affect how data structures behave. In conceptual math, there is no "computer" moving information around; the information just.. exists, hanging in a timeless void.

Arrays

An array may contain duplicate information, unlike a mathematical set. Otherwise, my intuition about arrays helped me a lot when learning set theory.

// :(
const bad: Array<number> = [1, 1, 1, 1];

Sets

Set (data structure) introduces a guarantee of uniqueness. But, a key distinction is that two mathematical sets containing identical elements are the same object.

// These are identical sets,
// but not the same object.
const A: Set<number> = new Set([1, 2, 3]);
const B: Set<number> = new Set([1, 2, 3]);

Consider that both A and B have unique memory addresses, effectively duplicating the contents of the set. Mathematical sets don't allow such duplication.

Armed with a proper intuition about how sets might behave on a computer, let's look at type systems.

Type Systems

Consider the following code:

const A: Array<number> = [1, 2, 3];

Here, number is a mathematical set containing all possible numeric values, and A is a mathematical set containing {1, 2, 3}. Therefore, A is a subset of number.

This nicely demonstrates why programmers like using strongly-typed programming languages.

A strongly typed programming language's compiler will strongly enforce that all of your variables are subsets of their type.

So, you couldn't have code like this:

const A: Array<string> = [1, 2, 3];

because neither 1, 2 nor 3 exist in the set of all possible strings.

But wait a minute! Both number and string are sets, but they don't consume memory in the way that [1, 2, 3] does! This property of "tangibility" is a key aspect of modern computer science, but mathematics has no such delineation between compile-time and run-time.

While learning set theory, adapting this intuition was by far my biggest struggle.

The Edge of Space

Imagine the x-y coordinate plane (formally, a Cartesian product of the real numbers, ℝxℝ).

The coordinate plane does not exist on some background-space. It isn't contained by anything. Rather, the coordinate plane just.. exists.

Computers, on the other hand, have a memory-space that contains everything. Absurdly, every variable in every running program is a subset of that memory-space!

Contrast this with types, like number, string, and Dog. These types are much more like the x-y coordinate plane: they don't really exist anywhere, rather, they define a space on which everything else is allowed to exist.

Such was my struggle when learning set theory from a CS-background. I came from a place where data exists somewhere, consumes space, and takes time to create. Pure math is timeless, beyond space, and honestly it fucking scares me. I'll stick with code, please!

Addendum: Code Example

I was building a little example while writing this article, and I decided to include it for fun.

Given two sets, A and B:

// A is a set
const A: Set<number> = new Set([1, 3]);
// B is a set
const B: Set<number> = new Set([1, 2, 3]);

we can define the subset function like so:

/**
 * @typeParam X - A type, like number or string
 * @typeParam Y - A type, like number or string
 * @param a - Set containing values of type X
 * @param b - Set containing values of type Y
 * @return true if a is a subset of b
 **/
function subset<X, Y>(a: Set<X>, b: Set<Y>): boolean {
    return a.filter(x => b.includes(x)).length === a.length;
}

subset(A, B); // true

Here, we see that X and Y are types. That makes them intangible sets (loose definition), because they consume no memory and you can't print them. Rather, X and Y define the possibility space of values which a and b are allowed to hold.

Further, we see that a and b are variables. That makes them tangible sets (by contrast), because they consume memory and can be interacted with. The type system guarantees that a is a subset of X, and b is a subset of Y, but it cannot guarantee that a is a subset of b. This computation, sadly, must be done at run-time.

That's all I've got.

Find me on github

Creating a Market Simulator at Work

Seth T.T — Tue, 05 Dec 2023 06:49:06 +0000

Cover image: Koondaiira on DeviantArt

Our team optimized and rebuilt a simulator for the futures and options (F&O) exchange.

What?

The F&O exchange is a massive software product with many moving parts. Cloud computers run multiple copies of the exchange simultaneously: some make up the real exchange that customers use, but most are just simulations. Software engineers often use simulations to verify their work and try new things.

Simulations are VERY useful for lots of reasons. We'll explore one in particular.

Quality Assurance

All customers hate buying shitty software, so it's mission-critical to fix every bug before selling your app or service. But the futures&options exchange is massive, and we're updating it all the time! How do you manage to catch all the bugs in such a big piece of software?

Automated testing is the answer.

The F&O exchange is rigorously vetted by automated testing suites. Each suite is powered by its own simulation, like in the picture. Suites interact with the simulation and watch its behavior for defects. This process automatically catches bugs, and it works quite well.

My role was to build a testing suite that behaves like a trader. The pretend-trader reads English descriptions of expected market behavior, then it trades on the simulated F&O exchange to ensure it's behaving as described.

Simulations for Sale

The process of creating simulations has been automated for quite some time, since so many of them are needed for automated testing. This production process is very intricate and brittle.

Here is the visualized production line for mass-producing F&O simulations:

These simulations are bulky and expensive since producing one is complicated. Developers spend a very long time reading deployment strategies, just trying to understand how simulations are made. Part of our team's work is to de-clutter the process of deploying a simulation. That way, (a) simulations are cheaper to produce, and (b) it's easier for devs to understand them.

What's Next

I have hopes, goals, and aspirations for the project, but it's technically company property so I don't want to accidentally get in trouble. With that being said, a one-click deployment process would be sick. Just push a single button, and bam! - you have a live, running F&O exchange allllllll to yourself. Kinda like a poke-ball for the F&O exchange.

Find me on github

Fantasy story about coding

Seth T.T — Wed, 22 Nov 2023 06:38:54 +0000

Hi, I'm Seth! I like interesting stuff. Read my article or perish.

A Work of Fiction

In ancient days, authors used language to write books for other writers. Education was scarce, and if you could read - you could write, too. It was a valuable economic skill and would not be wasted merely reading - create, goddamnit!

In the years preceeding the Apocalyptic Gargoyle Invasion (aka A.G.I.), a new type of book was engineered that would transform the United Continents of Htrae forever: a magical vessel, imbued with the powers of lightning and fire. The author, now, had a new tool at their disposal; and thus became a new entity entirely: the mage.

A mage was, ultimately, similar to an author because they used fancy books to describe problems for humans. The biggest barrier of entry, however, was the language used to express their arcane ideas. It was dissimilar to the common tongues of the time, full of strange symbols and vibrant colors.

an.example ? would("look") : like("this");

Imagine writing a book that describes a large problem to your reader, except the book itself is able to solve the problem just given your description of it.

The art of magecraft is to build literature such that the problems described are understandable by humans, but also lenient on the machines that run them.

That is what separates a well-written book from a poor one; a wizened mage from the scrappy apprentice.

In case you didn't catch it:

authors are, literally, authors

mages are programmers

magic books are computers

Ethics in Programming

Its far too easy to assume that if the reader understands computer code, then they must be able to simulate the workings of a computer inside their head. Code doesn't have to be pretty, it just has to work. This is prone to the same flaws as thick academic literature:

it doesn't matter how interesting the topic is, nobody will find it interesting if they can't read it.

When writing (code), place the reader first. Always. To progress in your programming skills means to learn new patterns and structures that allow you to communicate large, complex ideas elegantly - while being lenient on the machine that is destined to run them.

Final Thoughts

Have I met the goal outlined in the previous section? I don't know. The article itself is thoroughly dense, and less accessible because of it. My coding style is getting better, but still appears a garbled mess.

This article is not a reflection of my employer's values, nor my status as a programmer.
It is merely an expression of thought.

If you found this interesting let me know.
You can find me on github at https://github.com/stickyfingies.

DevOps: my faulty perspective

Seth T.T — Wed, 22 Nov 2023 06:31:19 +0000

Overview

Hello! My name is Seth, a third-year university student. I have nine years of independent coding experience, and have worked in software 'professionally' for approximately six months now (it's how I pay my rent).

Until recently, Developer Operations was a foreign topic to me. But, know it or not, DevOps is a huge part of how everybody writes code - and you do, too! (Unless you don't code.... that's cool, I guess.)

This article will help you understand DevOps from an "I've been there" perspective. I want you to understand internet articles about DevOps, and feel like you can learn something from Reddit conversations in those areas. It belongs to you -- own it!

A Weird Analogy

Physical products are bound to some rules of economics.

Small, reusable parts are regionally mass-produced. Big trucks ship parts between factories, where they combine to become larger, stronger parts.

This process may repeat itself.

Sometimes parts are sold directly, but other times they are shipped for further assembly and manufacturing.

Software (and other virtual products) share similar infrastructure, where small reusable classes or functions combine to form stronger, more capable libs or apps. Code is scanned, compiled, pushed, and pulled. It's a physical resource that moves between areas.

Here is what a software dev does for work:

Except it actually looks like this:

Big projects have longer assembly lines. Sometimes, it's so long that a human simply can't do it all. So it's mechanized, automated, and computerized - and what better way to accomplish this? You guessed it: using code.

Code Stuff

Let's look at our coding process:

Some code becomes part of the final product, after going through a factory.

Some code becomes the fucking factory.

Conclusion

DevOps is, ultimately, the art and craft of understanding how code becomes a product. It can be hard to notice in smaller projects because there simply isn't much manufacturing infrastructure to begin with. It grows by necessity.

Things you probably do

Manually test code (by logging "foo" and "bar")
Compile code and push to git
Deploy a website or change your download link

Things DevOps probably does

Automatically test code
Compile binaries through git hooks
Deploy-after-merge

Rest of article is TODO. I wrote this in twenty minutes and now I am going to bed.

Find me on Github

Event-driven cognitive framework

Seth T.T — Tue, 21 Nov 2023 02:17:11 +0000

Thought Constructs

Everything is information.
An event is information about something that happened, or something that changed.
A set of causes and a set of effects are associated with each event. Causes can be partially described at the time of the event. Some effects may be impossible to associate with their event, even after its time.

Code Constructs

Data is tangible and manipulable information. Everything is data.

data = {};
data = 123;
data = window;

Let Event be a generic type of data for explicitly labeling events.

/**
 * A generic type of data for explicitly labeling events.
 * @template What   - The type of data describing what happened.
 * @template Cause  - The type of data that caused this event.
 * @template Effect - The type of data which this event causes.
 **/
type Event<What, Cause, Effect> = {
    // what happened?
    what: What,
    // what caused it?
    cause: Set<C>,
    // what happens after?
    effect: Set<E>
};

Note that not all events may be explicitly labeled. Simple code can benefit from our vocabulary - we just need to think from a fresh perspective!

Let's examine a common TypeScript function - add(a, b).

/**
 * File: addition.ts
 * This code contains one system called `add`.
 **/

function add(a: number, b: number): number {
    return a + b;
}

This code contains one system called add. The add system has two inputs, called a and b, and it returns a single output.

Recall that we defined an event as information about something that happened, or something that changed. It sounds obvious, but a computer system executing the add function is - you guessed it - something happening!

Our return a + b is actually an event happening! Let's make this explicit using our Event type from earlier.

/**
 * File: addition.ts
 * This code contains one system called `add`, and its corresponding event.
 **/

type AddEvent = Event<number, typeof add, unknown>;

function add(a: number, b: number): AddEvent {

    return {
        what: (a + b),
        cause: new Set<>(add),
        effect: new Set<>(),
    } as const;
}

Obviously, this code is ugly and hard to read. What it communicates, though, is that even simple computer operations can fit within this cognitive framework.

Quest: Using `effect` to record the truth

Notice the effect section is empty. That's because at this point in the program's execution, we don't know yet what effects this function has on the rest of the program.

Let's fill our AddEvent with effects. Consider the following example:

import { AddEvent, add } from './addition.ts'

function main() {

    const a = 1;
    const b = 2;
    const $add = add(a, b);

    // Output: 3
    console.log($add.what);

    // Since we did something with $add, let's record it
    // as an effect. Now, $add is a complete and accurate
    // record of all that occurred by calling 'add(a, b)'.
    $add.effect.add(console.log);

}

This example adds unnecessary complexity to basic code operations for the sake of demonstration.

This API design also enables mistakes, because effects must be tracked explicitly and might be forgotten.

Conversely, tracing and understanding a program's causal chain is fucking invaluable. That's why developers log things.

Can we alleviate these API issues? What if a computer system could track it's own causal chain, as data? What if, indeed...

Let's try it!

Quest: Using `effect` to declare the truth

⚠️ TODO

Thank you for reading my article :)
Github

Coding Adventure: Karma as a System

Seth T.T — Fri, 06 Oct 2023 05:13:05 +0000

How can I use software to model Karma?

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?

My Design

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.

Karma describes processes and their outputs.
"Karma is a concept of action, work or deed, and its effect or consequences." — Wikipedia
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
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.
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.

Karma is the mechanism by which the qualities of a system's outputs may eventually influence the qualities of its inputs.

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:

What a quality is
What a perspective is
What a perceived quality is
... 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.

:~)

DEV Community: Seth T.T

Tech Story: C++ compiler behavior in a technical interview

My Response

Gut feelings

Use Resources

Analyze Evidence

Learn the Rules

On Commercial Software Evolution

Fitness Landscape

Dynamic Structure

The Commercial Software Market

Producers and Consumers

Agile Software Development

Technical Debt

A Solution

vcpkg - how to modify dependencies

Purpose

Project Structure

Step (1 of 4): Create a Local Registry

Step (2 of 4): Copy the Port Files

Step (3 of 4): Generating a Patch File

Finale (4 of 4): Use your Modified Dependency

My Struggle Learning Set Theory as a Programmer

Sets

Data Structures

Arrays

Sets

Type Systems

The Edge of Space

Addendum: Code Example

Creating a Market Simulator at Work

What?

Quality Assurance

Simulations for Sale

What's Next

Fantasy story about coding

A Work of Fiction

Ethics in Programming

Final Thoughts

DevOps: my faulty perspective

Overview

A Weird Analogy

Code Stuff

Conclusion

Event-driven cognitive framework

Thought Constructs

Code Constructs

Quest: Using effect to record the truth

Quest: Using effect to declare the truth

Coding Adventure: Karma as a System

KaaS

Eventually?

Qualitatively similar?

Quest: Using `effect` to record the truth

Quest: Using `effect` to declare the truth