The weekly Vivarium for Week 6

Better Futures Club

The meta-theme for this week is inspired by the book, "The Structure of Scientific Revolutions" by Thomas S. Kuhn.

Kuhn wanted to explain how scientific understanding and explanations evolve. The topics and subject matter are far too involved to do them any justice with a quick summary here, but they certainly provide an essential foundation for both attempting to understand the current "artificial intelligence" paradigm, as well as possibly illuminating how to accelerate and improve the "science of intelligence".

Despite the attention given to the mythical "Great Historical Figure" (e.g. consider Prometheus) who single-handedly discovers and explains some profound fact of existence, science is always a collective and communitarian endeavor.

After the pandemic turned the world upside down, technology has changed, a very-digital-native generation of kids have grown up, and a lot of other social dynamics are different, so how do you help a new community form in the current reality?

Better Futures Club

There are a pair of talks by David Deutsch that I wish everyone could watch.

In A New Way To Explain Explanation, he talks about how humans solved the mystery of starlight in about 40 years after having spent more than 100,000 years gazing up at the night sky and trying to explain what they saw.

And in The Unknowable & How To Prepare For It, he talks about how creating new knowledge always creates new problems as well, for which we need good explanations with which to solve them, and that takes us back to what are "good explanations".

We have an unlimited supply of problems to solve, and we have a powerful, demonstrated way to solve them. But are we making use of it?

It may seem like "intelligence" is extremely complex or even mysterious, but is it really so much more mysterious than starlight? It's not like we could go to the stars and sample them and yet we did figure it out. We're surrounded by intelligence, but how hard are we searching for good explanations of how it works?

Certainly not by creating things that parrot humans while consuming vast amounts of energy and other resources and producing many errors.

Last week I mentioned this post, but it's important enough that I'll mention it again: "The Gorman Paradox: Where Are All The AI-Generated Apps?".

There are a lot of problems that it would benefit us immensely to solve, but so far, what is claimed to be "artificial intelligence" hasn't shown much value in doing so. Sure, there are a few examples, particularly the work of the AlphaFold group, but we should be seeing hundreds of times more for the hundreds of billions of dollars that are pouring into LLM companies.

There's never a bad time to remember this statement by Margaret Mead:

Never doubt that a small group of thoughtful, committed citizens can change the world; indeed, it's the only thing that ever has.

Shane Becker is someone who has been around the Ruby and Rubinius world for a long time. He was a regular at Seattle Ruby, co-founded LA Ruby, created the Rubinius logo and some of the best Rubinius t-shirts ever, and many other things.

He has had a vision for a modern version of a creative space inspired by Bauhaus. This intersects well with what I have hoped for ever since I started contributing to Rubinius in 2006 and wanted people to be able to use programming languages to solve problems.

Together, we're going to run a weekly meetup in Portland under the banner of the Better Futures Club. We'll be meeting at the PDX Hackerspace on alternating Tuesdays and Thursdays starting in January. You can find the events on Luma and Calagator.

Components & Interfaces

Just like humans are inseparable from their communities and associations, "programs" or "applications" are always collections of distinct parts or "components"—in a very broad sense of something that has identity with a boundary that distinguishes it from other things.

Sometimes people like to talk about "monoliths" or "monolithic applications" ("mono" from Greek monos ‘alone’, and "-lith" from Greek lithos ‘stone’) as if they were, to reference the above, something like Prometheus, standing alone, apart, above, etc.

Nope, it's just where you draw the boundaries. So a "monolith" typically wouldn't include the operating system, the device drivers, the TCP/IP networking stack, etc. Not everyone would agree, there are still probably one or two Unikernel people out there.

Software applications, or more generally, things that describe computation, are always collections of things.

And between things, there is some sort of boundary, and some sort of interaction. Unless those billiard balls are sitting on the table and nothing ever happens. Then it's just boundaries and no interaction.

Lambda Calculus

One of the simplest ways to define computation is the lambda calculus. In just a few sentences, it's possible to define a means to describe any possible computation:

Variables (taken from an alphabet);
x – A simple variable.
Abstraction (function definition); and
λx. M – A function with parameter x and body M.
Application (function invocation).
M N – Applying function M to argument N.

There are some details about binding and scope of variables that are important. You can read up on that.

Computation in this system is also defined extremely simply. It's a single rule called β-reduction:

(λx. M) N → M[x := N] – Replace all free occurrences of x in M with N.

What would it look like if we introduced boundaries into a sea of computation?

Actors

The "actor model" is a formal model of concurrent computation. It is also extremely simple. It was defined by Carl Hewitt in 1973 and formalized by Gul Agha in 1986 (see Actors: A Model of Concurrent Computation in Distributed Systems).

An actor is an entity that, upon receiving a message, may do exactly three things:

Send a message to other actors;
Create a new actor; and
Change its own behavior for the next message.

These are some properties of actors that arise from this definition:

Actors communicate only by asynchronous message passing.
There is no shared state.
Each actor processes its messages sequentially.
The order in which message are delivered is not guaranteed.
There is no global clock or global state.

Some of the properties of actor-based computation are also interesting:

Every actor has an identity (an address).
Messages are sent to actor identities.
The core operation is sending a message, not calling a function.
Sending a message does not block the sender.
There is no return value from sending a message.

An "actor system" is one where many actors execute concurrently, even though each actor handles messages sent to it one at a time. Hence, concurrency is a system attribute, not a component attribute.

Interfaces

Actors and the lambda calculus are truly fascinating systems. Elegant, simple, and yet as capable as it is possible to be (i.e. able to express any possible computation).

Why then did we not use something like this when we began to build systems of communicating parts? Why did we consider that the interactions between components needed to be something mediated by an "interface definition language" (IDL) instead of computation?

An IDL is a generic term for a language that lets a program or object written in one language communicate with another program written in an unknown language.

Here are some examples of the mechanisms that have been proposed to define the interaction between systems:

CORBA
Distributed Component Object Model (DCOM)
Protocol Buffers
JSON Web-Service Protocol (JSON-WSP)
OMG IDL
Web Services Description Language (WSDL)
...

By my count, there are at least 30 such things listed on that Wikipedia page above. Compared to the definitions of lambda calculus and Actors, wow, that's a lot. I wonder why we'd need so many of those?

Why not Computation?

Unison is a newer programming language that has a couple value propositions.

It is advertised as a new approach to distributed programming where there is "[n]o more writing encoders and decoders at every network boundary. Say where you want computations to run and it happens 🔮 — Dependencies are deployed on the fly."

That sounds exactly like what I've been trying to get across. I wonder why Unison didn't go the "IDL" route?

Did I mention there was going to be homework this week...

News Around Your Towns

If you're in the Portland Metro area, we'd love to see you at a Better Futures Club meetup in the new year.

I'm also going to check out some of the other events happening around town and probably propose a talk to any that may be interested. I'll report on how that goes.

Reader's Corner

Reading groups are a great way to engage new material with others. They are also pretty easy to do online. There's a ton of material out there about various models and theories of intelligence. Is anyone participating in a reading group focused on exploring these? Let us know at news@vivarium-ai.com.

We’ll send occasional updates about new docs and platform changes.

How's it Tracking?

It is believed that Euclid said, "There is no royal road to geometry." The meaning being that not even a king gets a shortcut to understanding something like mathematics.

The Rubinius LLVM backend is the third major LLVM component and second LLVM backend that I've worked on and each time I believed there could be a shortcut. Each time it seems like there must be a way that doesn't require scaling such a high stone castle wall protecting the vast LLVM riches within, but alas... Perhaps I've learned my lesson.

So progress continues on warping a previously working but totally different backend into one for Rubinius, not entirely unlike turning a bunch of rusty nails into a knife blade. (You should definitely watch that video, you'll thank me.)

London Calling...

Rubinius, Vivarium AI, and Better Futures Club are all on Bluesky as verified (via domain name) accounts. The whole open-source and social media ecosystems have evolved a lot in the last decade from what they were in the early Twitter days. Where are conversations happening and what are people talking about? We'd like to ask you for a favor: follow those or suggest accounts to pay attention to.

Looking Forward to Next Week

We're rapidly running out of days in the 2025 allotment. I know the holiday season is busy for people and many things are demanding attention. In the northern hemisphere, it's also winter and the plants and seeds may look dormant but there's activity underground, ready for spring.

I've written a lot about the various pillars of the Vivarium system, except for infrastructure. To be useful in helping to easily explore existing approaches to machine intelligence, test them, and experiment with them, the whole system needs to be efficient and as easy to interact with as possible. So, I'd like to get a reference system running that embeds at least one interesting intelligence model in an agent component and illustrates an interaction with the other system elements.

Here's hoping you are spending time with friends and family as this year wraps up.

References

Dec 21, 2025