A unit test in EO is an attribute of the object it tests, and it comes in exactly two kinds: the object can do something, or it cannot. Two arrows spell the difference, ++> and -->, and since the end of July a lint refuses to let the name of a test disagree with the arrow that declares it. It reads like bureaucracy. It is the cheapest design review we have.

Four years ago we introduced the error and try objects: error wrapped an object and threw it up the stack, try caught it, extracted the payload, and ran a finally block. It worked, but it was Java smuggled into EO — 𝜑-calculus has no exceptions to throw and no stack to unwind. What it does have is ⊥, the bottom — a computation that terminated. Recently we deleted try and error and gave the bottom a spelling of its own: the letter T, which we call the terminator.

Most languages keep unit tests at a distance from the code they verify: a parallel source tree, a mirror class with a Test suffix, a framework that finds tests by annotation or naming convention. The distance is the problem: mirrors go stale, tests drift, and “where are the tests for this?” becomes a question worth asking. In EO we reduced the distance to zero. A test is an attribute of the object it tests, declared inside the object, in the same file, in the same scope.

In 𝜑-calculus, a formation may be applied on the spot: the expression ⟦a ↦ 7, x ↦ ∅⟧(x ↦ 42) forms an object with one void attribute and immediately supplies the argument. EO had no way to say this. A formation first had to receive a name, and then a separate application had to repeat that name. Recently we closed the gap with a new syntax element: a line that starts with |, which we call a pipe.

People keep asking us why EO exists, since the world hardly needs yet another programming language. It is a fair question, and it deserves a straight answer. EO is not trying to out-comfort Java or out-hype Rust. It is a research instrument pointed at one old, specific, and still unsolved problem: object-oriented code is pleasant for programmers to write and expensive for computers to run.

Until recently, an object in EO was whatever a single .eo file said it was. If you wanted number to know how to raise itself to a power, you either grew number.eo until nobody could read it, or you parked the operation in some other object with a made-up name. We took a third road: an object and the package named after it are now the same thing, so number is defined by number.eo and by every file under number/.

Ask two EO programmers to lay out the same object and you may well get two different files. One stacks everything vertically, another folds it onto a single line, and both are correct. We would rather the compiler decided, and always arrived at the same, prettiest answer. So we taught it to score every possible layout and pick the one that hurts the least.

A while ago we explained what the >> syntax stands for: it auto-names an abstract object when a meaningful name is unnecessary, and the compiler quietly generates a random unique one under the hood. Recently we let this same >> carry a handle of your choosing, and this small change gave EO a new way to hide things. We call it “encapsulation by obfuscation”.