A Path Not Taken

Source: Dev.to

Institutional Knowledge Loss

As these systems grow and evolve, the institutional knowledge required to maintain, fix, and enhance them also expands. Shifting markets, political fluctuations, and employee attrition lead to a loss of this knowledge. Corporations often back‑fill positions with fresh talent without realizing that it can take months or years for most people to master such complex systems.

Sequential Nature of Code

Much of the complexity can be traced to microprocessor architecture. Microprocessors operate sequentially—load, execute, store, branch, and return billions of times per second—always following the instruction counter. Consequently, programming languages behave similarly. Modern CPUs can process instructions in parallel across multiple cores, but the code itself remains sequential. Operating systems support concurrent/parallel processing via threads and cores, yet the underlying code is still sequential.

Limiting Pattern in Traditional Code

Over the years I’ve observed a recurring pattern:

• Code collects data elements to be used as input arguments.
• It calls a function and inspects the results upon return.
• The data elements are often gathered by calling other functions, requiring all inputs to be ready before invoking the target function.

This works in many cases, but it becomes problematic in event‑driven systems where data arrives asynchronously. Polling for each missing element leads to inefficiency and defeats parallelism. Stacking multiple polling loops prevents the system from utilizing idle time for other processing. While moving polling to separate threads is possible, it introduces additional concurrency controls and inter‑process communication overhead.

Desired Programming Model

My colleagues and I imagined a model where:

• Data elements could arrive at any time, in any order.
• The same data element could be delivered to different functions simultaneously.
• Functions could execute asynchronously as soon as all required data elements were available.
• The location and number of function instances were dynamic.
• A standard, consistent architecture made software easier to understand and maintain.

Related Concepts

These ideas are not entirely novel. Earlier work includes:

• Kahn Process Networks (KPNs) – introduced in the 1970s for signal processing.
• Flow‑Based Programming (FBP) – also from the 1970s, where asynchronous processes consume data chunks arriving over streams.

Cellular Programming Model

We centered our notion around Cells that process Stimuli arriving over Synapses.

• Cells can be connected in any topology, including multiply‑connected configurations.
• Synapses transmit stimuli locally or remotely; cell location is transparent to the system.
• Stimuli traverse the network, triggering Activators in interested cells.
• A cell may host multiple activators, which can be independent or interrelated.

We refer to building such systems as Cellular Programming.

Development of NeuPaths

While some colleagues focused on a cellular operating system, I set out to prove that the idea is generally useful. Over many years I:

1. Built a framework for cellular programming.
2. Experimented, discussed, and repeatedly rewrote the framework to tackle general‑computing tasks.
3. Designed sophisticated protocols for discovery, subscription, and routing to meet performance demands.
4. Optimized cells to consume minimal resources, especially while waiting for stimuli.

In 2025 I presented the framework NeuPaths to the software community. Despite my “Field of Dreams” optimism—believing that publishing alone would spark adoption—interest has been limited. The framework lacks a single, tangible definition; it is described as “anything you want,” which makes it hard to convey concrete value. Nonetheless, I invite anyone interested to experiment with cellular programming and collaborate on new ideas.

Invitation

Explore and create with NeuPaths, available on GitHub:

https://github.com/commence-software/NeuPaths