I've been writing C for 35 years. Somewhere along the way I came to believe that every working developer should be fluent in at least one compiled language and one scripting language — that they cover different parts of the same craft, and being good at only one leaves you reaching for the wrong tool half the time.
For most of those years I kept the question in the back of my head: if I were to write a scripting language, what would be in it? I never quite answered it, because I never quite had the time. DominScript is what came out when I finally did.
This is the story of how I got here.
The Clipper '87 years
It started in the late 1980s, on DOS, with a database tool called Clipper '87. I was working at the Paks Nuclear Power Plant, in the Chemistry Department, and we had mountains of data — measurements, trends, calibrations, samples — flowing in from instruments and inspections. Clipper was wonderful for what it did: dBase-compatible storage, a respectable record-oriented language, character-mode forms and reports. For data entry and listings, it was everything we needed.
But character mode has limits. The engineers wanted to see their data — curves over time, plant diagrams with live values overlaid, the shapes that numbers make when you draw them. Clipper couldn't do graphics. Turbo C could.
I already knew C from school — programming was what I'd trained for — so the Turbo C side was familiar ground from day one. I wrote the graphical pieces as extensions and called them from Clipper. The result was a system where the boring parts — schemas, queries, navigation — stayed in a high-level tool, and the interesting parts — visualization, custom calculation, anything Clipper couldn't reach — were written in C and plugged in alongside.
For the engineers, the difference was enormous. They went from staring at columns of numbers to actually understanding what their plant was doing. For me, it was something else: a feeling of complete freedom. Whatever the high-level tool didn't cover, I could just extend in C, and it became part of the same system. No FFI bindings, no glue layer, no "you can't do that here, you need a different stack." Just: write it in C, call it from the script.
That feeling stayed with me. I spent the next thirty years half-consciously looking for it in every other environment I worked in.
Four percent of the server
Many years later I was at TV2 in Hungary, in the team responsible for the SMS business. Among other things, that meant we ran the live voting for shows like Big Brother and Megasztár — Hungary's version of Idol. During an episode, hundreds of thousands of SMS votes would arrive within minutes, and the TV studio needed real-time statistics on screen as the show went out live.
The setup worked, but I had a fear that wouldn't let me sleep: what if the database engine fell over during the broadcast? Not "later we'd debug it" — there was no later. The host was on camera, the audience was watching at home, and the numbers on screen had to be the right numbers, right now. If the primary stack failed, we would simply not have a story to tell the studio. There was no second system.
So I built one. A real-time log-analysis system, reading the same operational data the database was processing, but from a completely independent pipeline. The goal: if the database died, my system would carry the same numbers to the studio, and nobody outside the control room would know anything was wrong.
The sysadmin gave me 4% of the server's CPU during a live show. He said: if you go above that, I shoot you down.
At first he did shoot it down. The first few attempts were too greedy, and out the process went, mid-broadcast. But over the following weeks I optimized — every hot loop, every allocation, every code path. Eventually the system ran the whole way through an episode under the budget, and stayed there. It became the trusted shadow that gave me back my sleep.
The interesting part wasn't the optimization. It was that the log analyzer had grown into something curiously general-purpose. Adding a new event type, a new aggregation, a new view of the data — it kept wanting a real scripting layer, and I kept hand-coding it in C. By the end I was convinced: this thing wants a script language of its own.
The language I always wanted to write
After TV2 I separated the log analyzer from the broadcast context and made it a project of its own — a flexible, programmable, customizable system that anyone could adapt to their own data. And that's when the old question came back: if I were to write a scripting language, what would be in it?
This time I knew what I wanted. The first thing, the non-negotiable thing, was that the language itself stays small. Not because small is fashionable, but because every capability you bake into the interpreter is a capability you can never escape from. If the interpreter knows about HTTP, then HTTP comes with it everywhere, even when you don't need it. If it doesn't, you load a plugin when you need HTTP and ignore it otherwise. The interpreter stays the same size it was on day one.
The second thing was that the language should look like C. Not for nostalgia — for a reason. When you write something in a strongly-typed, C-shaped language, and one day you discover it needs more performance than a script can give, the path from your .dom file to a C plugin is short and mechanical. Variable names, types, control flow, struct layouts — they all map directly. You don't rewrite, you translate. The work you put into the script is not lost when you move on.
This is the Clipper-and-Turbo-C combination, thirty-five years later, finally as one coherent system: a high-level layer where you do most of your thinking, and a clean path down to C for the parts that need it. The same freedom I had in 1989, except now the high-level layer is a real language with types and validation, and the C side is a proper plugin API instead of a sea of __cdecl declarations.
Everything else in DominScript follows from those two decisions. Plugins as shared libraries. Three validation passes before anything runs. Zero-copy at the script/plugin boundary. Packed structs that map directly onto C structs. The skeleton plugins that show you how to extend it yourself. None of it is academic; all of it is what I wanted in my own work, and never quite had.
That's why I built it. After 35 years, this is the scripting language I would have wanted on day one — and I built it the only way I knew would last: small core, strong types, real C underneath, and a path that doesn't throw away your work when the requirements grow.
If any of this sounds like something you've also been looking for, you might enjoy what we're putting together. The technical details — what's in the language, what's in the plugin set, how it's tested, when v1.0 ships — are all on the main page.