Welcome to the Barry and Friends blog!

Introduction

My name is Máté Birkás and I'm the creator of the Barry programming language. When someone tries to introduce a new programming language they must first answer the burning question of why? Sometimes the question is longer and often incoeporates some inappropriate language as well. Strangely nobody asks the same question from people who decide to write a new computer game. It's obvious that they just want to entertain their audience and make some money while doing so. Or the other way around. Either way, basically they're doing it for fun.

On the other hand every new programming language carries the aura of menace and danger as it appears on the horizon, and less tenacious coders start to tremble under its seductive powers, secretly knowing that they will pay the price dearly if they fall for the temptations of their new intellectual overlord. Programmers are suspicious creatures from experience, and what they are really asking is "what price will I pay for falling for these new shiny promises?". They already suspect that programming is suffering, and while the best engineering effort might make it bearable, it's inherently not fun for a deeper reason or two.

I created Barry and the project around it, because I'm convinced that we can do better. We seem to have every software technology and knowledge to make a paradigm shift and make our programming tools just as enjoyable to use as our computer games and other professional applications. The price we have to pay is to break with some 50-year-old traditions, practices and fixtures that served us well, but the time has come for their well deserved and yet dignified retirement.

The Modern Way

I'm coming from the VFX industry, where it's pretty common to deal with billions of 3D primitives like particles or voxels. Sometimes we display them in a 3D viewport, sometimes we edit them in a spreadsheet form. But we always store and process both data and structure in binary form. Either way the applications have means to render the binary data in several forms and then they're mapping back the edits to the binary data, even if the edit was textual in nature.

There were definitely some applications that tried to store data in plain text, but the advantages of binary floating point pushed them out from the market.

Another architectural property that every capable application shares to a certain degree, is that they organize data into trees. Sometimes these trees serve an organizational purpose, other times it allows optimizations, sometimes it's just the easiest way to implement something. Trees are basically easy to program, easy to optimize and easy to cache.

Now programming languages also happen to be trees. When we compile a program we build an Abstract Syntax Tree from the character soup of the source. Basically every programming language is a textual serialization format for an AST.

With Barry I'd like to prove that by making this serialization bi-directional we can build a programming environment that is architected like a modern application: storing the AST in binary form in memory, and presenting it for the user for inspection and editing in many possible forms. The standard notation of the language being only the default: the baseline user interface of the application.

For this I need to integrate the editor, the compiler and the runtime into one continuous and consistent experience that allows the users to edit, run and inspect their code while it's evaluating.

A Computer Game for Programming

Dagger is Barry's first practical implementation. It runs in the browser. It is a single file of pure JavaScript with no external dependencies: no internet access, no backend, no imports of any kind. It uses the standard Web APIs the browser provides, like the Canvas element for rendering the source code. (No, it doesn't use the DOM either as, it's not quick enough for our purposes.)

Like every modern application, Dagger is architected around an event loop, which in this case looks something like this:

The system applies incremental compilation mechanisms to minimize the work of updating the tree and generic caching mechanisms including proper invalidation to minimize the work of evaluating the changed results. It might seem weird that these features take priority over things like function definitions, but they're essential for proving that the performance I crave for is sustainable as the tree grows.

We only use strings as temporary edit buffers: we never store the code in a textual form, we render it from the AST. This also means that the system works as it's own formatter by architecture. As we can render the syntax highlighted standard notation onto the canvas for editing, we can also emit it as a plain text for the usual serialization purposes like transmission or storage.

The State of Affairs

The latest "stable" version of Dagger is v0.0.9 and by stable I mean that I patched most of the bugs and most disturbing child illnesses I discovered. Even the most essential features are missing. To put it bluntly: the system is not yet not yet Touring-comlete.

Despite being in its early infancy Dagger already shows some promise, as users can already describe basic calculations with it, and even reuse them by using stems and feeding. These features resemble Haskell's curried functions or partial expressions in other languages, but they're just the first baby steps of the concept of trees as return values.

JavaScript, or ES2024 as I like to call it, might seem like a silly choice for a language implementation. Barry came to be as a user facing scripting language for an application I was developing. It was born in the browser and later stayed in it, because it suited it surprisingly well. While JS is somewhat incohherent at places, but it can be used something like a flexible C and can be acceptably performant at it. I gain a built-in rendering framework with it, that's capable of rendering text and geometry acceptably fast, so I can concentrate on the language more. But most importantly it has the lowest cost of entry: you type a URL into a browser and you can use the environment to program. Since the code is not transpiled or minified, you open the developer tools and can inspect the code of the language implementation with a debugger. Literally under 3 seconds.

It also became obvious very early - at least for me -, that Barry is more interesting and possibly more important than the original project that it grew out from. The original project's backend was written in Go and I didn't give up the plan to integrate the two, so most probably the next implementation of Barry will be in Go. At the moment I'm aiming to reach a certain level of parity with the language specification to make that move worth the effort.

You can look at the specification written in a fittingly questionable style in the Barry.md file of the repository. Nothing is stable at the moment. The whole project is in a ductile state, as the implementation is providing significant feedback that's actively refining the language itself.

Buzzwords and Inspirations

If someone would put a gun to my head I would say Barry is a Lisp-like functional language, that will use some disciplined time abstractions to allow non-deterministic mutations on the computation tree, and a meta-data layer that allows both higher level abstractions and low level optimization in the form of constraints enforced on sub-trees.

The design is influenced and inspired by mostly everything that happened and existed in the last 50 years of programming and reached my mind. From Assembly to Minecraft the honorable mentions in no particular order are:

And of course a lot of inspiration came in the form of practices and examples I realized I want to avoid. I'm infinitely grateful for both kinds of inspiration.

Demo

Please check out the belonging demo video .