MetaZen started out as an idea of mine way back in the early 1990's. I realized early in my software development career that I was rarely going to have the opportunity to innovate. Most of my time was going to be spent doing menial tasks, with only a few nuggets of interesting coding sprinkled into the mix.

Wow, that really sounded like a boring way to spend the rest of my life. What a huge waste of time.

Ever since then it's been my goal to change that.


My original project was called Concept. The premise was that if I could express my ideas in written form using natural language (creatively named Concept Programming Language), I could have the computer do all of the boring stuff.

I quickly came to realize that most human languages are not expressive enough and have too many ambiguities to be useful. I learned a whole lot about natural language processing, but ultimately I had to admit that I was going down the wrong path.

Over the years I improved my skills and I learned more about software design and programming languages.

I started thinking that Lisp (and then later, Clojure) might be my answer, because those languages, being declarative instead of imperative, would lose fewer important details. It was easier to determine details of a design when they were expressed in an explicit manner instead of implied.

What I didn't understand was that I was still trying to make certain decisions that ought to be reserved until much later… so much later that those details would become irrelevant.

Via Clean Architecture we know that we can defer certain decisions fairly easily. What database are we going to use? What message passing system? Even decisions previously difficult to defer, such as thick client, mobile vs web, can be deferred pretty easily these days.

Two of the hardest decisions to defer is programming language and GUI Framework.


A few years ago I started working on figuring out how to defer the latter, by having data description (initially using JSON) that expressed enough details as to allow dynamic GUI (initially using Aurelia) for fairly simple CRUD applications.

I was able to get pretty far with this approach, and was even able to use the data definitions to drive the schema for Zen Spaces as well as create an application for editing the meta data.

Still, this wasn't good enough. Too much of the application still had to be hand written; especially tedious was the event handlers when targeting an event sourced architecture.

Meta Programming

Eventually, decades later, I started designing a new programming language called ZScript.

The first generation of this language was essentially Lisp, except I reversed the syntax for defining macro's (`). In Lisp, the default is the code that you write is intended to be executed immediately, and the ` symbol is used to define a macro. With ZScript I reversed that, so the default was macro creation and you had to use a special function (eval) to execute something.

The second generation of the language added support for executing the resulting code in a Reactive / Event sourced manner, and you could subscribe to the results in the host language (C++ and JavaScript at the time).

After learning more languages, specifically TypeScript, Rust, and Clojure, I came up with some language enhancements that allowed me to implement types (mostly using the TypeScript syntax), and support classes, records, and interfaces drawing inspiration from Rust traits and Clojure protocols, deftype, and defrecord.

Additionally, other than in special cases such as eval, the resulting code is never executed, nor is it intended to be executed.

ZScript, in this final(?) form, is a meta programming macro language, and it's used as the input to code generators that generate code specifically for the target language and frameworks.

Welcome to the world of Meta Programming.

Current State

I'm currently prototyping a TypeScript code generator targeting minimal library code, but as with all Clean Architectures, these libraries are accessed via interfaces and could easily be replaced with different implementations.

The code generator implementation is fairly straight-forward and is also accessed via interfaces via a plugin system. This is a key component. The code generator must be fairly simple and easy to write, otherwise it'd be simpler just to re-write everything in a new language / framework and be done with it.

Voila! Now, every single previously considered major architectural decision has been made irrelevant.

What Programming Language?

Dunno… who cares?

What GUI? React? Angular? wxWidgets?

We can figure that out later, and we'll probably not need any of them; we'll just code directly to the metal for GUI's.

What database are we going to use?

Database? Do we really need one? Dunno… who cares?

Now we can focus on the truly important decisions.

Welcome to MetaZen.

Looking Forward

Over the next few months I'm going to (hopefully) continue making progress on ZScript and MetaZen while implementing some concrete examples. When I come across something that might make for an interesting example, I'll share the meta data and show some of the resulting generated code.