About CX
Some things just need to be done. CX is one of those — not because everyone is screaming for another file format, but because we aren't. We put up with XML's verbosity because it was expressive and could hold real structure, unlike CSV, INI, or ENV. Then JSON arrived and we never looked back: easy to read, often leaner than XML, fast to parse — and oh so lacking. We cared about solving the problem in front of us, not the cost. We love to talk about what's good in new tech; we rarely count what it costs.
The rock in our shoe
Then came YAML, then TOML. Great — now instead of a few verbose XML documents, my project carries four or five config formats. So much for DRY: what won't fit in one gets split across two or three, with references pointing back and forth. And we get to waste hours in team debates over which format goes where. Project after project, we just keep walking on the same rock in our shoe.
Doing something about it (2024)
A better data format had been on my mind for a long time. In 2024 I finally did something about it. The first sketch looked like YAML — but YAML is a poor wire format and not very expressive, so I switched to a curly-brace form: a more concise XML, with real data types. Then I started cutting every character that needs the shift key (yes, I'm that lazy). Drop this here, move that there, and eventually I had a CX that out-expresses XML for both data and prose while running 20%+ more concise than JSON — and, in most cases, close to YAML.
From format to language (2026)
The project bounced around until 2026, when I jumped in full steam and stood
up a parser across 10–12 languages. As the patterns settled I added
substitutions, anchors, and eventually a template engine. Tinkering with the
templating, I started adding a few functions — and remembered how easy data
manipulation is with XPath and XQuery. I've spent years as a lead Principal
Engineer and consultant on hundreds of projects, many of them mission-critical
enterprise systems, and I tend to see data as one of three things: stored,
transformed, or on the move — ETL patterns from the micro to the macro,
everywhere. I'm a big fan of separating read and write paths, of messaging, of
distributed systems. So I thought: let's experiment with CX as a language,
too. I'd always liked the low impedance between JavaScript and JSON — and XML
with XQuery is better still. After trying a few approaches I landed on
something special: a homoiconic language, where data and code share
the same structure and the same parser, with just a few extras for the code
side. It reminded me of LISP, so I leaned into a LISP-1-style design — even
though I'd never loved all those parentheses. Brackets [ ] simply
suited me better, read better, and (of course) take no shift key.
What I wanted in it
CX really is easy to type and easy to read, with a little patience. I gravitate toward things that are uncommon but make plain sense — the Dvorak layout, for one. So I kept adding what I'd always wanted in a data format and a language, drawing on the 30–35 languages I've worked in. I like functional programming but I'm no purist; objects have their place, but plain data structures are usually good enough and dodge a lot of pain. I wanted a language that was visualizable from the ground up — easy when it's homoiconic — that made parallel processing simple, and that treated networking and error handling as first-class, world-class concerns.
What it turned into
Somewhere in the middle of all this I realized what CX had become: easier to use than Python, the best blend of data and code I'd worked with, data and prose as first-class siblings — and far faster than Python while staying type-safe, auto-typed, and dynamically interpreted. On a single core, HTTP throughput clocked in at 800 requests/second for Python, 60k for Node.js, and 135k for CX. Scaling across cores isn't there yet — I have work to do — but an M2 MacBook Pro should reach 300–500k+ requests/second.
Put together, CX is a data language that can land serious capability in the enterprise. It's full-featured already, though it still needs raw pounding to harden. It also has capability enforcement built in — strong security by default. And one more thing: CX is uniquely positioned to be an agentic language. Think about what might make one language better than another in an agentic ecosystem.
Why the name
CX originally stood for Concise XML. I wanted to bring back XML's
expressiveness — and enhance it — while dropping all the friction, landing
somewhere terser yet still readable, closer to YAML. Then, by chance, as the
language evolved its core pattern came into focus: the bracket head,
[name …] — or, at a glance, just [x. And there's the
name again.
CX is great for plain data, config files, and documentation — prose and data living together in harmony. But now it's also a language, bursting out of the gate. I hope you enjoy it. It's been a lot of fun to create, and simply something I had to do.