This is the first in a series of posts I want to write about both building Ceptr and coding in Ceptr. In many of them I jump right into the middle of deep tech, so hold on to your horses, and enjoy!
I want to start out with a few key points of what Ceptr might look like to you from a programmer's perspective:
In Ceptr you should not think of yourself as programming a computer, but rather a network of simple computers some of which are embedded inside each-other. We call these simple computers receptors.
The fundamental data unit in Ceptr is not a 32 or 64 bit word; it's a semantic tree. Now this may sound weird, but it creates an important mental shift. Think of each receptor as a computer whose CPU operates by evaluating tree structures, not linear sequences of bits. The "program counter" doesn't move forward along a linear memory space, loading the next instruction into a register for evaluation but rather walks along a tree structured memory space recursively reducing branches down to their result.
Not surprisingly, Ceptr programs are just another type of semantic tree. This means that fundamentally the Ceptr programming environment is homeoiconic.
Ceptr uses an expanded version of Regular Expressions for pattern matching, that we call SemTrex (SEMantic Tree Regular Expressions). Regular Expressions are designed to scan a linear sequence of characters, but SemTrex expressions operate on trees and can match on semantics as well as value.
Ceptr provides a native signaling system for you to send messages between these receptors. Much of Ceptr programming is about expectations which trigger code when signals arrive, based both on explicit pattern matching on the content of the arriving signal (using SemTrex), and based on the entry path of the signal (kind of like known port numbers in TCP/IP). Thus, the Ceptr "instruction set" includes support for rich inter-receptor communication, including single message sending, request-response patterns, and persistent connection based "conversations," and most importantly patterns for defining multi-receptor protocols.
These protocols can be defined as abstractions, kind of like template classes. Thus, lots of Ceptr programming involves thinking about what agents are doing in a given protocol, and what the interactions of that protocol are, and finally building more complicated protocols out of simpler ones.
I know this is all abstract. In future posts I'll get into the nitty gritty with actual code examples. Here's a list of some the topics I hope to cover in more depth:
Semantic trees, semantic alternation and, especially, what it feels like to code when you can't use data without thinking about what's the semantic use of that data
Homoiconicity, and how in Ceptr, like in a few other programming languages, a program's representation and structure match closely, making meta-programming much easier.
Templates, slots, grammars & parameters: the marriage between the known and the unknown, and the core of composability.
Transcoding: the semantic version of cast or type conversion.
Phenotype vs. Genotype, or as programmers would say: class/type/prototype vs. instance.
Coherence contexts: beyond namespaces.
Protocols as live, pluggable code rather than as specifications for coding.
Scaffolding systems into existence, or, as a Alan Perlis put it in his epigrams: "Everything should be built top-down, except the first time." and how this applies to Ceptr.
So if any of these sounds particularly interesting tell me in the comments, and I'll push that higher in my priority list.