WTF is 'Xlerb'?

Starting Forth's Text Interpreter Character (the butler) attempts to look up XLERB in the Dictionary. The Numbers Runner just laughs at him, as the word has not been defined. He presents 'XLERB', with a question mark, back to the user.

Starting Forth, p.18. The Text Interpreter tries to execute the word XLERB only to be absolutely roasted by the Numbers Runner. What if there was a "Xlerb"?

If we’ve already got great stack lanuguages already like gforth, factor and uiua, as well as great Beam languages in Erlang, Elixir and Gleam, then why throw a new one int the mix? Why write a new language at all? Why do anything?

If Python is ‘batteries included’, I like to see Erlang as ‘nuclear reactors included’. With built-in pattern matching, immutability as standard, message passing, process supervision and networking, preemptive multitasking, incredible cinema, and so much more, it’s remarkably easy to implement a language with these features right out of the box.

These fundamentals are pretty syntax-agnostic - process-to-process communication is an idea, less so a construct. Same for immutability and so on. So with such a lovely compilation target, programming language designers are left free to add a new perspective: with Elixir, we got a clean-slate compilation stack, a fabulous macro system and more arguably more approachable syntax; LFE brings the Lisp way of things, Gleam adds a HM type system. All monotonic additions to this base.

No but, really, wtf is Xlerb?

Primarily, it’s a piece of interactive artwork. But wait, there’s something in this! Look at this table:

vowel b g
a bag gag
o bog gog
u bug gug
i big gig
e beg geg

These are all 3 letter words which start with a b or a g, and end in a g. Note how only the bold ones actually mean anything in English. The rest don’t exist. The patterns are there, there’s nothing inherently illegal about the word “gug”, but it just has no meaning.

Let’s take a detour for a moment and talk about coordinate spaces:

The equations of motion for the x and y coordinates, of a point orbiting another point at 60RPM at a fixed radius are this:

\(\begin{align*} x(t) &= \cos(2\pi t) \\ y(t) &= \sin(2\pi t) \end{align*}\) where $t$ is in seconds.

Expressed in polar coordinates, it’s shorter. Note that you don’t even need to know what Polar/Euclidean coordinates even are here - the polar coordinate version has objectively fewer characters:

\[\begin{align*} r(t) &= 1 \\ \theta(t) &= 2\pi t \end{align*}\]

Now, what happens if the radius of orbit also changes over time, at a rate of one meter per revolution:

\[\begin{align*} x(t) &= r(t)\cos(\theta(t)) = t \cos(2\pi t) \\ y(t) &= r(t)\sin(\theta(t)) = t \sin(2\pi t) \end{align*}\]

In polar coordinates, this would be written as:

\[\begin{align*} r(t) &= t \\ \theta(t) &= 2\pi t \end{align*}\]

Clearly, we’re on to something with these Polar coordinates! Using a radius ($r$) and angle ($\theta$) seems to be a natural fit for talking about motion with rotational symmetry - I only had to change $1$ with $t$ in the definition of $r(t)$.

It’s not objectively better, just a better fit for this problem.

I look at programming languages in much the same way - as coordinate systems for addressing some high-dimension solution space. Some problems naturally lend themselves to be expressed more succinctly in some languages than others.

Sending a message to another machine in C:

int sock = socket(AF_INET, SOCK_STREAM, 0);
struct sockaddr_in addr = {
    .sin_family = AF_INET,
    .sin_port = htons(12345),
    .sin_addr.s_addr = inet_addr("192.168.1.2") 
};
connect(sock, (struct sockaddr*)&addr, sizeof(addr));
send(sock, "hello", 5, 0);
close(sock);

Sending a message to another machine in Erlang:

Pid ! Message.

This is obviously hiding all of the complexity in how the ERTS actually does this stuff, and indeed at the end of the day it does use Sockets (or not!), but that’s the whole point! In picking Erlang as the notation, it lets us just express the problem with none of the repetitive incidental complexity and ceremony.

Same for solving constraint problems in prolog, solving matrix operations with Numpy, proving theorems in Agda. You could solve N-queens in Python, but you’d have to spin up the whole DP table yourself. You could implement a Neural net in fully reversible, pure Prolog with constraint-based arithmetic, but you’d most likely run out of memory and have a nightmare debugging it.

At the end of the day these languages (indeed any programming languages which is well-designed) lend themselves to expressing and solving problems in a simple way in such a way that makes their programs

  • short and comprehensible, where as much of the code is the actual problem at hand, rather than boilerplate
  • well-aligned with the problem space, such that moving in the ‘space’ of the code (applying diffs, changing it) translate as close as possible to a move in the problem space being modelled.

So what does our accidental gaps table look like for programming languages?

In the below table I’m calling the soul of the language the sort of ‘main idea’ that that programming language embodies.

This may be a particular runtime or paradigm - the idea that in a JVM language you’re never getting away from objects, that in APL the best solution involves arrays, in Prolog you’re doing logical relations, on the BEAM you’re not getting away from the schedulers and processes etc.

How that soul is expressed is in the syntax and semantics of the language you end up writing. We get something like this:

Soul Lisp ML Algol Forth
CLR Clojure CLR F# C# -
APL April - - Uiua
JVM Clojure Scala Java -
BEAM LFE Gleam - Xlerb

We’re right at the bottom there. A Forth-ish language with the soul of the BEAM; where we push around atoms, send and receive messages, run millions of processes.

So what’s the point in Xlerb? I don’t know! I don’t know what problems the BEAM solves well that are best expressed in terms of stacks, and maybe there are none! But just how inventing particle accelerators led to nuclear medicine, or mouldy melon led to penicillin breakthroughs, maybe (lmao) Xlerb will lead to some cool thing that no one thought of yet.

I’m already thinking, for example, it might actually be a nice way to do live music coding (strudel, tau5, supercollider etc).

In any case, we can’t know until it exists!