Why a New Language?

1. In the Beginning, There Was Machine Code

In the beginning, there was machine code. At the lowest level, every computer program consists of zeros and ones. These binary patterns encode instructions that the processor executes directly: moving data, performing arithmetic, comparing values, and jumping to different locations based on conditions.

01001000 10001001 11100101
01001000 10000011 11101100 00001000
10001011 00000101 00000000 00000000 00000000 00000000

In the earliest era of computing, this was the only way to program a machine. The programmers who worked on ENIAC in 1945, and on EDSAC just a few years later, lived in this world. They didn't write code—they wired circuits and flipped switches. When stored-program computers arrived, they punched cards with numeric opcodes.

It’s hard to overstate how unforgiving—and how literal—that was. At that level, zeros and ones weren’t “data types”; they corresponded to physical states: voltage on a wire, a relay position, or a vacuum tube being on or off. Early programmers didn’t just “write code” — they were often working close enough to the hardware that the constructs they cared about were the machine’s own guts: registers, addresses, and bit patterns.

That’s a recurring theme in the history of programming: as the *problem space* changes, the language evolves so its constructs match what people actually care about. When you’re building a computer, bit patterns are a reasonable abstraction. When you’re trying to make software repeatable, reusable, and fast to change, you need different primitives.

Assembly Language: Naming the Zeros and Ones

Before assemblers, there was a small mercy: hexadecimal. Hex wasn’t invented for computers — it’s ancient — but it became newly useful here. It didn’t change what the machine executed, but it gave humans something to recognize: patterns, boundaries, and chunks you could scan without counting bits.

48 89 E5
48 83 EC 08
8B 05 00 00 00 00

Assembly language emerged almost immediately as a response to this problem—as early as the late 1940s on machines like EDSAC at Cambridge. Instead of writing binary encodings, programmers could write symbolic instructions and labels that an assembler would translate into the underlying zeros and ones.

section .data
    msg db 'Hello, World!', 0

section .text
    global _start

_start:
    mov rax, 1
    mov rdi, 1
    mov rsi, msg
    mov rdx, 13
    syscall

Assembly did not change the paradigm. Control flow was still explicit and imperative. But it made the machine's behavior legible to humans. This was the beginning of a long trend: making the computer do more work so the human could think more clearly.

And once you have an assembler, you have something bigger than a nicer notation: you have a new kind of workflow. You write one program, and then you run a program to translate it into something the machine can execute.

Put differently: an assembler is itself a computer program. You run it first, and it outputs a new artifact—the machine code your computer will actually run. That means the “act of programming” becomes a two‑step process: write code for humans, then run a program that turns it into code for machines.

This matters because early computer time was incredibly valuable, and yet people still spent some of that precious time on tools that made programming faster, safer, and more repeatable. Almost immediately, we took the new machine and put *other programs* between humans and hardware—so the machine could help us use the machine.

You also get early building blocks for reuse and repeatability. Labels and named routines let you turn “the sequence of steps I do all the time” into something you can call again and again—one of the roots of the subroutine and the function.

From there, the ladder of abstraction rose quickly. In the late 1950s and 1960s, early high-level languages like Fortran, Lisp, COBOL, and ALGOL showed that you could describe computation in terms closer to the problem—math, symbols, business rules, structured control flow—while compilers handled the low-level details. APL pushed this idea even further, compressing entire computations into a dense notation that made the *computer* do more work so the *human* could say more with less.

Lisp: Code as Data

Lisp emerged in the late 1950s with a different kind of ambition: make symbolic computation practical. One of its defining ideas was that code and data share the same shape — which made programs easier to generate, transform, and reason about. Lists, recursion, and symbolic manipulation weren’t accidental language features—they were the constructs the researchers cared about.

(defun hello-world ()
  (format t "Hello, World!~%"))

(hello-world)

C: Structured Control Flow

One especially influential descendant of this era was C. Programmers could write structured control flow—functions, loops, conditionals—without manually managing jumps and memory addresses. The compiler handled translation to machine code. The CPU still executed imperative instructions. But humans could now reason about behavior at a higher level.

#include <stdio.h>

int main() {
    printf("Hello, World!\n");
    return 0;
}

Crucially, the mental model remained unchanged: the programmer still fully specified how decisions were made. The abstraction moved up a level, but the paradigm stayed the same.

C++ and Object-Oriented Programming

C++ and object-oriented programming pushed abstraction further by trying to match a new problem space: large systems made of interacting “things” with state and responsibilities. Instead of reasoning only about control flow, you could reason about entities, boundaries, and relationships—then let the language and runtime enforce some structure.

#include <iostream>
#include <string>

class Greeter {
public:
    std::string name;
    Greeter(std::string n) : name(n) {}
    void greet() {
        std::cout << "Hello, " << name << "!" << std::endl;
    }
};

int main() {
    Greeter g("World");
    g.greet();
    return 0;
}

Ruby: Pseudocode as Code

Languages like Ruby represent another step along the same trajectory: express intent more directly. Ruby deliberately prioritizes expressiveness and readability, allowing code to resemble structured pseudocode. The computer does more work on behalf of the human so the human can focus on the problem, not the bookkeeping.

class Greeter
  def initialize(name)
    @name = name
  end

  def greet
    puts "Hello, #{@name}!"
  end
end

Greeter.new("World").greet

But the role of the programmer had not fundamentally changed. The programmer still described the control flow. The computer still followed instructions.

These examples aren’t meant as a tour of “important languages.” They’re snapshots of a repeating pattern: as software changes, programmers want their language to expose the constructs they actually reason about — and hide the ones they don’t.

The Pattern Repeats with AI

Today, we're seeing the same pattern repeat. One of the first valuable uses of AI has been to turn it on itself: using AI to write better code, to make programming easier. GitHub Copilot, ChatGPT writing functions, Claude refactoring modules—these tools follow the same trajectory that began with assemblers in the 1940s.

Tactus continues that tradition: it raises the level of abstraction to match what engineers actually care about in agentic systems — procedures, tool use, guardrails, checkpoints, and evaluation — so you can express those concerns directly.

World = Agent {
    model = "openai/gpt-4o-mini",
    system_prompt = "Your name is World."
}

return World("Hello, World!").output

But this time, something deeper is changing. It's not just another layer of abstraction over imperative code. The way decisions are made is fundamentally different. Control flow is no longer something you fully specify in advance—it emerges from interaction between models, data, and constraints.

For most of computing history, progress in programming meant raising the level at which humans describe imperative control flow for a CPU. What comes next is not another step along that same line. It is a change in direction.

3. Why Existing Languages and Frameworks Start to Strain

At first glance, it's reasonable to ask why any of this requires a new language at all. Python, TypeScript, and other general-purpose languages are flexible, expressive, and powerful. Entire ecosystems of agent frameworks already exist, layered on top of them.

The problem is not capability. The problem is fit.

General-purpose programming languages were designed around an imperative mental model. Even when they support functional or declarative styles, they still assume that control flow is something the programmer explicitly encodes. When stochastic, behavior-driven systems are built in these languages, the core concepts are typically bolted on rather than represented directly.

# Trying to make Python do agent workflows
async def process_with_agent(input_data):
    try:
        result = await openai.chat.completions.create(...)
        # Now what? How do we checkpoint?
        # How do we test this?
        # How do we prevent it from reading /etc/passwd?
        return result
    except Exception as e:
        # Hope for the best?
        pass

Procedure {
  function(input)
    local result = agent {
      instruction = "Process this input",
      data = input
    }
    -- Designed for durable checkpoints
    -- Designed for sandboxed execution
    -- Designed to be evaluated with specs
    return result
  end
}

As a result, the essential structure of these systems becomes fragmented. Decision-making logic lives partly in code, partly in prompts, partly in configuration, and partly in external models. Tool usage, retries, fallbacks, approvals, and evaluations are implemented as ad hoc patterns rather than first-class constructs.

This creates a mismatch between how the system actually behaves and how the language encourages the programmer to think. The code describes steps and branches, but the system operates as a procedure whose behavior emerges from interaction between models, data, and constraints.

When control decisions move into the model, “the code” can become a thin wrapper around the real moving parts. You end up managing the most important concerns — guardrails, tool capability boundaries, evaluation criteria, and human checkpoints — through scattered conventions instead of first-class constructs.

Tactus is designed to close that gap: to let you express procedures and guardrails in a form that matches the problem you’re actually solving, so your code is aligned with how the system runs.

5. Why MLOps Alone Is Not Enough

Machine learning practitioners have been dealing with stochastic systems for years. They don't talk about correctness; they talk about metrics, experiments, and optimization. They have tooling—MLflow being a canonical example—for tracking runs, comparing models, and selecting better-performing variants.

It helps, but it doesn't fully solve the problem.

MLOps is optimized around models, not behavior. The primary unit of evaluation is a model trained to perform a narrowly defined task, measured using relatively simple, quantifiable metrics such as accuracy, precision, recall, or loss.

Agentic systems are different. They do not just produce predictions; they take actions, use tools, interact with external systems, and generate multi-step behaviors. Success is rarely captured by a single scalar metric. Two runs may both succeed while differing significantly in how they arrive at that success.

Specifications are the missing piece. To evaluate behavior, specifications themselves must become more flexible. They must be able to express constraints, expectations, and boundaries without requiring identical outputs.

7. PrOps: Operating Procedures, Not Just Code or Models

Once behavior becomes the primary unit of concern, it becomes clear that neither DevOps nor MLOps fully describes the operational problem we are trying to solve.

DevOps is built around operating deterministic programs. MLOps is built around training and serving statistical models. Agentic systems do not fit cleanly into either category. They are not just programs, and they are not just models. They are procedures: systems that combine imperative logic, learned components, tools, constraints, and evaluation into a single decision-making process.

This is the gap that PrOps is meant to fill.

In a PrOps mindset, deployment is not a binary event. A procedure is introduced, evaluated against behavioral specifications, compared to alternatives, and iteratively refined. Changes are assessed based on how they affect observed behavior, not whether they preserve identical outputs.

Human judgment becomes a first-class component of the system. Humans define what acceptable behavior looks like, design evaluations to capture it, and make decisions about whether a procedure is ready to be relied upon.

9. Conclusion: Evolution, Not Alien DNA

It's important to be precise about what has changed—and what has not.

From the perspective of computer science theory, nothing fundamental has broken. These systems still run on conventional hardware. They are still composed of instructions. They are still Turing-complete. There is no new computational substrate, no alien machinery hiding beneath the surface.

What has changed is the way decisions are made and, more importantly, the way humans must reason about those decisions.

For most of computing history, programming meant specifying control flow in advance. Languages, tools, and best practices evolved to make that process safer, clearer, and more efficient for humans. That entire ecosystem was built around deterministic execution and binary notions of correctness.

Today, many of the most important systems we build no longer operate that way. Decisions emerge from learned behavior, probabilistic inference, and interaction with the world. Control flow becomes dynamic. Outcomes are evaluated empirically. Variation is expected, not eliminated.

This is not a revolution in computation. It is the next stage in a long, continuous effort: helping humans work effectively with increasingly powerful machines, as the nature of decision-making itself evolves.