Saving a 1950s Artificial Language for the Age of Artificial Intelligence

torrua — Thu, 01 Oct 2026 18:59:38 +0000

Why would anyone rescue a human language designed on punch cards — in the era of neural networks?

This article is submitted for the Hacktoberfest Weekend Challenge.

In 1955, a sociologist and science fiction writer named Dr. James Cooke Brown set out to answer a question that philosophers and linguists had debated for centuries: does the language you speak shape the way you think?

To test this — the Sapir-Whorf hypothesis — he didn't study existing languages. He built a new one from scratch: Loglan (Logical Language).

The goal was ambitious: create a human-speakable language based on first-order predicate logic, free of syntactic ambiguity. Every grammatical sentence in Loglan has exactly one parse tree.

Decades later, a dedicated community of researchers, linguists, and hobbyists still speaks and expands Loglan. (Its better-known descendant, Lojban, forked in the 1990s and carries a different grammar — but the original Loglan corpus remains the older and more tightly formalized of the two.) Until recently, the master dictionary — the Loglan Online Dictionary, or LOD — lived in legacy @-delimited flat text files (Words.txt, WordDefinition.txt, LexEvent.txt) managed by scripts from the 1990s.

When the tools keeping a niche language accessible break down, the language fades.

So I built LOD Manager: a cross-platform, local-first desktop and mobile dictionary editor powered by Tauri v2, Svelte 5, and Rust.

What I didn't expect was the realization that came along the way: Artificial Languages and Artificial Intelligence have been working on the same problem — from opposite ends.

Artificial Language & Artificial Intelligence: Two Sides of the Same Coin

We talk endlessly about Artificial Intelligence but rarely about Artificial Languages. Yet both were born from the same mid-20th-century intellectual explosion that gave us cybernetics, information theory, and cognitive science — and they clashed almost immediately.

In 1957, two years after Brown began Loglan, Noam Chomsky published Syntactic Structures and wrote a critical review challenging whether a formal grammar could fully capture a human language. It was a direct polemic about the limits of formalization in language — the exact same debate that plays out today when we ask whether structured output formats can make LLMs reason reliably.

The Trap of Ambiguity

Human languages are messy. The Winograd schema ("The trophy didn't fit in the suitcase because it was too big") exists because natural language relies on world knowledge to resolve syntax. LLMs spend billions of parameters on disambiguation that a well-designed formal language would never need.

Loglan was engineered to eliminate this. Its grammar was designed to be machine-checkable — and by the 1980s it had been validated with LALR parsers to confirm zero syntactic ambiguity. Here is what that means in practice:

English: "Pretty little girls' school."
How many ways can you parse this? At least five: a pretty school for little girls, a small school for pretty girls, a pretty and small school for girls, a school for girls who are pretty and little, and more. English grammar gives you no way to tell which one the speaker meant.

In Loglan, each of these meanings is a different sentence. The grammar particles (ge, ci, and others) force the speaker to specify exactly what modifies what. You can't produce the phrase without choosing one parse — ambiguity literally cannot arise. (The Loglan Institute uses this exact example as a demonstration of the language's core design principle.)

This is why a Loglan corpus is structurally interesting for AI evaluation: every sentence is its own ground truth. No human annotation needed to establish the "correct" parse — the grammar guarantees it.

Sapir-Whorf for Machines

Brown created Loglan to test whether human thought could be freed from the irrationalities of natural language.

Today, we're asking the same question of AI: does representation shape reasoning?

When an LLM outputs free-form prose, it hallucinates.
When we constrain it to structured schemas — JSON, DSLs, typed tool calls — reliability goes up dramatically.

In hindsight, Loglan was asking the same question that prompt engineering asks today: can you improve thinking by improving the language you think in? Brown just asked it seventy years earlier, and his "prompt format" was an entire human-speakable language.

The Neuro-Symbolic Opportunity

AI research is moving from pure statistical pattern-matching toward neuro-symbolic approaches — combining neural networks with symbolic logic. To evaluate whether a model genuinely reasons or merely pattern-matches against natural language noise, you need test corpora with deterministic parses and explicit semantic categories.

The Loglan dictionary already has these properties built in: every word carries a type classification (primitive, complex, affix, little word), every definition tags keywords with explicit «keyword» markers, and the predicate structure assigns fixed argument slots (x1 gives x2 to x3). These aren't annotations I added — they're the native structure of the language, designed decades before anyone imagined benchmarking neural networks.

The catch is that none of this is useful while it's trapped in @-delimited text files from the 1990s. It needs to be relational, searchable, and open. That's what LOD Manager exists to do.

Why Desktop, Not Web?

Before choosing a stack, I tried a few other paths. A PWA couldn't open external .db files from disk. IndexedDB can't work with arbitrary SQLite databases that maintainers bring. Electron worked, but resource usage was absurd for what is essentially a search-and-edit interface over a 2MB database. I briefly considered a pure CLI tool, but dictionary browsing needs a visual UI — you're constantly cross-referencing words, affixes, and etymologies.

That left a native-shell approach. The constraints were clear:

Offline-first. Linguists and field researchers work on planes, in libraries, off the grid. The dictionary must work with no network. On my mid-range laptop (Ryzen 5, 16GB), cold start is ~180ms; warm start is under 100ms.
Data ownership. Maintainers need to open arbitrary .db files, import legacy text archives, and export standalone HTML dictionaries with one click.
Lightweight. The production binary is 8MB. Idle RSS is ~45MB. Compare that to a typical Electron app.

This led to Tauri v2 + Rust + SQLite (FTS5) + Svelte 5. Several developers on DEV have written about the same Tauri-over-Electron calculus — the tradeoffs are real, but for a data-heavy offline tool the choice was clear.

Architecture

┌──────────────────────────────────────────────────────┐
│              Frontend (Svelte 5 + TS)                │
│ Virtualized Word List · Custom Chips · Reactive Search│
└──────────────────────────┬───────────────────────────┘
                           │ Tauri IPC (30 typed commands)
┌──────────────────────────▼───────────────────────────┐
│                  Rust Backend (Tauri v2)              │
│ State Management · rusqlite · HTML Exporter · FTS Sync│
└──────────────────────────┬───────────────────────────┘
                           │
┌──────────────────────────▼───────────────────────────┐
│                Local SQLite Database                 │
│  Relational Schema + FTS5 Full-Text Virtual Tables   │
└──────────────────────────────────────────────────────┘

SQLite FTS5: Four Ways to Search

Loglan lexicography is bidirectional: Loglan→English and English→Loglan. For English full-text search, LIKE '%query%' degraded fast over tens of thousands of definitions. I built on SQLite's FTS5 with the unicode61 tokenizer, using a content-synced table so that inserts and deletes go through the main definitions table and triggers keep the FTS index in lockstep:

CREATE VIRTUAL TABLE def_fts USING fts5(
    body, usage, notes,
    content='definitions',
    tokenize='unicode61 remove_diacritics 1'
);

This became a 4-mode engine: FTS5 full-body (ranked BM25 with snippets), FTS5 keywords-only (searching «keyword» tags), LIKE fallback (for external databases without FTS tables), and prefix/wildcard filtering across affixes and compounds.

Svelte 5 Runes

Migrating to Svelte 5 Runes ($state, $derived, $effect) was the biggest quality-of-life upgrade in the project. The old store-based reactivity caused cascading re-renders when filtering 10,000+ words. With Runes, I deleted about 40% of my reactive store code and nothing broke. That's when I knew the migration was worth it:

<script lang="ts">
  let words = $state<WordSummary[]>([]);
  let searchQuery = $state('');
  let selectedType = $state<string | null>(null);

  const visibleWords = $derived(
    words.filter(w => {
      const matches = w.name.toLowerCase().startsWith(searchQuery.toLowerCase());
      const typeMatches = !selectedType || w.type === selectedType;
      return matches && typeMatches;
    })
  );
</script>

Paired with a virtualized sidebar renderer (28px row height), scrolling through the full lexicon stays at 60 FPS.

Typed IPC

All 30 Tauri commands are typed end-to-end. If a Rust struct in models.rs drifts from the TypeScript interface in types.ts, the compiler catches it before any user does:

#[tauri::command]
pub async fn get_word(
    state: State<'_, AppState>,
    id: i64,
) -> Result<WordDetail, String> {
    with_db(&state, |conn| db::get_word(conn, id))
}

Hard Lessons

Foreign keys without cascade. The legacy Loglan schema had M2M tables (connect_words, connect_authors, connect_keys) generated without ON DELETE CASCADE. I enforce PRAGMA foreign_keys = ON in LOD Manager — so the first time I tried to delete a word, SQLite threw a constraint error. I spent two evenings tracing foreign key violations before realizing every delete needed explicit child-row cleanup in a transaction block. The fix was straightforward once I understood the schema; finding it was not.

Android content URIs. On desktop, opening a database is opening a file path. On Android, the user picks a file and gets a scoped content:// URI — which SQLite refuses to open directly. I had to write a stream-copy bridge that reads the URI through Android's content resolver, writes to a temporary app-local path, and opens that. It took a full weekend to get right, including handling permission revocations on app restart.

Incremental FTS sync. When a maintainer edits a definition through the UI, the FTS5 index must stay current. My first attempt — rebuild the entire index on every save — worked until someone edited 30 definitions in a row and each save took 400ms. I moved to trigger-based incremental sync (delete old row, insert new row) which brought per-save cost under 5ms. Small table, big difference in perceived responsiveness.

Why I Build

When Brown and his team engineered Loglan in the 1950s–70s, they were working with the sharpest tools available: mainframes, punch cards, and — after Chomsky's Syntactic Structures appeared in 1957 — a brand-new theoretical framework for formal grammars. By the 1980s they were feeding Loglan into LALR parsers on Unix workstations. Each decade, the best available technology was pointed at the same question: can language be made precise enough to change how we think?

Seven decades later, I reach for Rust, Tauri, and Svelte. The tools couldn't look more different. But the question hasn't changed.

Technologies change. Our fascination with the mind simply takes different forms.

In 1955 it was an artificial language. In 2026 it is artificial intelligence. The medium shifts; the curiosity endures. And building open tools that keep these experiments alive — that is the work worth doing.

Explore & Contribute

LOD Manager is MIT-licensed and open source:

📦 GitHub: github.com/torrua/LOD_manager
🛠️ Stack: Tauri v2, Rust (2024 edition), Svelte 5, TypeScript, SQLite FTS5
🐛 Good first issues: open issues

Whether you're interested in computational linguistics, building local-first apps, or want to help test on Linux or Android — issues and PRs are welcome.

What do you think about the relationship between constructed languages and AI? I'd love to hear your perspective in the comments.

DEV Community: torrua