Sublime By Contract

Over and over again, I am amazed by the genius of separating the What from the How.

From the micro-level of interfaces to the grand schemes of protocols, the inherent beauty of The Contract is cool. For two reasons:

• it clearly defines the expectations
• the brilliant, creative solutions to Gettin' It Done

Example 1: The History of Couriers

The contract: get stuff from A to B, in X time units, for money. Classic.

From the Pony Express to banzai bicycle messengers, onward up to FedEx and UPS, each step of the courier business is an intriguing story. I don't know if there is a popular history of couriers but there should be. The pioneering spirit is abundant and the technology is outrageous. Fascinating.

Example 2: IP over Avian Carriers

It is a silly example but delights me now as much as it did when I first read about it, ages ago. Birds and nerds team up for some networking mojo.

Example 3: Inversion of Control

In the early days of Java, it was very neat to use Collection, List, and other interfaces because of the latitude of changing the implementation; e.g. one might go from a HashMap to a TreeMap, based on profiling. Swing and distributed computing use 'em all over.

For straight-up apps, though, it seemed like we never really changed the implementation, even with factories, but it was cool nonetheless. We could change them if we wanted to.

Then came the IoC containers and the interface had a resurgence: Version 2.0. Now, it's very easy to change out implementations. It's a great feeling to use a set of mock objects for daily unit tests and a full-blown DB implementation during nightly integration testing. More than just using a contract, it's the tactile sense of different implementations. A sense of change.

Example 4: Terracotta

I recently went through the Hello Terracotta exercise on Alex Miller's blog. Check it out.

Terracotta is the latest mind-altering idea I've come across. I'm not even sure that I understand the implications of what it does, just yet. It really makes one say 'wow' and 'huh?' at the same time.

I do understand that it is sublime by contract. Get this: it honours the semantics of the Java Memory Model, and yet in doing so, it dopes up your (designated) classes and JVM so that it can shuttle your data to a central service (this phenomenon is called Network Attached Memory). In the simple example, one's app/JVM can go up and down and yet work with 'persistent' objects.

The kicker is that your code doesn't need to know: there is some serious mojo under the hood, and yet the contract of the Java Memory Model still holds.

If the standard JVM is a bike courier, Terracotta is UPS. Your stuff still gets done, but more efficiently.

There are some ideas that wouldn't occur to me even if I were on a desert island for 100 years. One of them is separating -- in such a weird way -- the contract of Java memory semantics from the implementation.

That's sublime.