Atomic programming

What is it and how does it work

Over the course of its history, programming evolved from linear programming (i.e. typing commands) to “blocks” programming (i.e. visual programming environments). We introduce the next generation of programming: Atomic programming.

To use an abstract analogy, imagine switching from today’s mechanical prosthetic arm that is made of plastic, titanium, silicone, etc to a prosthetic arm that is grown from human cells and tissue. The biological arm has a significantly better sensitivity, feedback and movement support than the mechanical one.

Similar is the qualitative leap from linear or block programming to Atomic programming. Each Atomic component is like a biological cell that responds to stimuli. The larger compounds of Atomic components have more complex reactions and motivation, and constitute software that evolves and morphs depending on the builtin goals and requirements, and the context it operates in.

What is an Atom?

Let’s dive into how Atomic programming actually works. Within the software, we have a basic code unit called an Atom:

Every Atom is defined by its inputs and output. 
Atoms are reactive - they only do work if one of their inputs changes.

Composition of Atoms

Atoms can be composed into compounds by connecting their inputs and outputs. 

Modularity and Decoupling

The Atomic components are modular and have no interdependencies. The data is decoupled from business logic, decoupled from UX, and so on.

This allows any module to be modified or replaced without affecting the stability of the rest of the system. It’s like replacing a tire or an engine while you drive.

In this paradigm, developers have the freedom to control every choice of underlying technology or service provider, or alternatively fall back to the framework’s deliberation for decisions they don’t want to make.

Every component is easily pluggable. For example, the developer may specifically choose Firebase storage and later replace it with a Fission storage. On the other hand, the developer may just request an abstract persistent storage, and let the framework choose one.

Moreover, each component can stand on its own, and developers have the freedom to run their components independently, outside of the Atom54 framework. 

Cross Device / Multi device

The modularity and dependency-free architecture allows the Atomic software to run on any device or combination of devices, on any platform or OS.

Like any other implementation aspect, the UX is pluggable and optional. Atom54 experiences can include no UX whatsoever and run as background server tasks. 

The decoupling of UX also allows Atom54 to render UX onto any rendering surface (for example, DOM), or multiple surfaces and devices.

The framework manages the cross device orchestration of components, while being transparent for the developer.

Composition of compositions

A composition of Atoms can be treated as a logical Atomic unit of itself.  It is similarly defined by its inputs and outputs. And in the same way as the basic Atoms, the compositions of Atoms themselves are composable by connecting inputs and outputs.

Due to its composable nature, the Atomic software is future ready and adaptable to innovations yet to come.

Similarly, the Atomic software can also be composed with standalone classic software via this universal data-flow determined API.

To learn more about Atom54, please visit our website, repository, read our blog or get in touch.