The Lineage of ELIZA: A Code-Phylogeny Study

Central Inquiry: Is it possible to construct a comprehensive family tree of ELIZA implementations by analyzing the underlying source code?

This report details the current progress of the ELIZAGen project. This initiative treats various versions of ELIZA not merely as software, but as biological specimens, applying the rigorous methodologies of phylogenetics to trace their evolution.

For over sixty years, ELIZA has been reborn countless times. It has been ported across diverse languages, reconstructed from academic papers, stripped down for classroom instruction, and repurposed as conceptual art. Because software lacks the physical continuity found in biological DNA or handwritten manuscripts, the project ignores raw text in favor of comparing architectural blueprints.

🧬 Methodology

Instead of a direct text comparison, each program is evaluated based on a set of abstract architectural traits. This creates a character matrix where each feature is binary: $\text{Feature} \in \{0, 1\}$

This matrix is then processed using PAUP*, the industry-standard software for parsimony analysis in evolutionary biology.

The Current Dataset

Specimens: 27 distinct programs.
Timeline: 1965–2025.
Diversity: 8 different programming languages.
Metrics: 13 binary features.

The findings are currently being detailed in a draft paper: Reconstructing Program Genealogies from Abstract Program Descriptions: The ELIZA Case Study (A Work in Progress) by Jeff Shrager (December 2025).

The Analytical Pipeline

🌳 The Phylogenetic Tree

The most parsimonious tree (generated via PAUP* and rendered with Bio.Phylo) reveals a fascinating distribution. In this model, horizontal distance represents the branch length, which corresponds to the number of architectural changes.

1. The Root (The Core Architecture)

At the base of the tree are programs that are architecturally identical. Despite being written in different eras and languages, they preserve the full original design:

Weizenbaum’s 1965 original (MAD-SLIP).
Bernie Cosell’s 1966 Lisp version (built independently from the CACM paper).
Various other Lisp iterations.
1970 versions in SNOBOL and Burroughs B5500 Algol.
A modern Java version and Anthony Hay’s 2021 C++ reconstruction.

2. The Branches (Adaptation & Simplification)

Branching away from the core are primarily BASIC versions from the early microcomputer era—mostly descendants of Jeff Shrager's 1973 BASIC ELIZA (published in Creative Computing, 1977). This group also includes Python, JavaScript, and streamlined Lisp versions.

These descendants typically exhibit a loss of complexity, specifically:

~~Backtracking~~
~~Memory systems~~
~~Keyword priority~~

These omissions occurred due to the hardware constraints of early PCs, the needs of pedagogical examples (such as Norvig’s 1991 Lisp in PAIP), or shifting programming paradigms.

3. The Test Cases (Validation)

To verify the accuracy of the method, three specific specimens were used:

The Clones: E18 and E20 are byte-for-byte identical; they correctly appeared together with zero branch length.
The Control: E22 is a pattern-matching file utility ~~not designed for conversation~~. Because it nested within the ELIZA clade, it proves the current features detect general pattern-matching architecture rather than conversational intent.
The Outlier: LadyMouth (E21, by Sarah Ciston) is a feminist critical-art bot. It scored zero on all features and sits at the maximum distance, confirming it is an "ELIZA" by role and critique, not by code.

🛠️ Technical Implementation

The project argues that this tree is not a literal lineage of "parent" and "child" code, but rather a map of a textual tradition. It illustrates how software is preserved, adapted, or reimagined through convergent evolution.

Workflow Checklist

Collect source code from archives and repositories.
Normalize text (remove comments, standardize whitespace).
Use an LLM to suggest initial structural features.
Perform round-robin manual curation until the vocabulary stabilized.
Score every specimen against the frozen vocabulary.
Convert the matrix to NEXUS format for PAUP* analysis.

The 13 Architectural Features

Feature	Description
Rule-based pattern matching	Logic is driven by explicit rules/patterns rather than statistical or procedural logic.
Keyword priority	Rules have numeric weights to determine which takes precedence.
Synonym translation	Normalizes various surface forms into a single canonical token.
Backtracking matcher	Can consume variable segments and backtrack to satisfy complex patterns.
Wildcards classes	Supports token classes or placeholders (e.g., numeric segments).
Segment storage	Saves matched input segments for use in the response.
Template reassembly	Builds responses by inserting stored segments into templates.
Memory rules	Specifically stores and retrieves past inputs via dedicated rules.
Fallback rule	A "catch-all" default rule for when no other patterns match.
Punctuation-sensitive	Uses explicit separators/breakers to shape tokens.
Ordered memory	Recalls stored memories in a specific sequence rather than randomly.
List/symbol processing	Relies on `list-and-symbol` manipulation over raw string processing.
Separable script	The conversation script is logically distinct from the processing engine.

Sample Data Matrix (Partial)

Below is a representation of how specimens are scored ( $\checkmark$ = present).

Specimen | Rule-Based | Priority | Synonym | Backtrack | ... | Separable
-----------------------------------------------------------------------
E01 (Cosell66) |    ✓       |    ✓     |    ✓    |     ✓     | ... |    ✓
E18 (Clone A)  |    ✓       |    ✓     |    ✓    |     ✓     | ... |    ✓
E21 (LadyMouth)|    ☐       |    ☐     |    ☐    |     ☐     | ... |    ☐