Elements of Clojure

In the software literature, sometimes "transparent" means transparent, and sometimes it means opaque. This week, I explore the history behind both uses, and try to find a synthesis: explaining.software/archive/transp…

For the next few weeks, we'll be exploring both sides of this coin. To start, we'll look at the simplicity of keeping things apart: explaining.software/archive/the-si…

This intuition arises from our industry's decades-long treatment of coupling as, at best, a necessary evil. And, in my opinion, it's entirely wrong. Cohesive code doesn't have to be understood all at once. Rather, it's best understood incrementally: explaining.software/archive/the-si…

Almost every discussion of simplicity in the software industry builds atop the coupling/cohesion dichotomy introduced by Stevens et al in dl.acm.org/doi/10.1147/sj…. There, they defined relationships inside functions as "cohesion", and every other relationship as "coupling".

I wrote about why coupling has an unfair reputation in software design explaining.software/archive/coupli…

I wrote about the three-part structure of explanations in software development: explaining.software/archive/the-an…

For the past few years, I've been working on a book about software design. Lately, I've been feeling the need to ensure that its core ideas resonate with a broader audience. As such, I've started a newsletter: explaining.software/archive/a-brie…

I recently gave a talk on some ideas from my upcoming book on software design: youtu.be/tHThXQr7wwA. There’s a lot I didn’t have time to cover, but I think it conveys the general perspective I’m taking and some of the central themes.

Elements of Clojure leanpub.com/elementsofcloj… by Zachary Tellman is the featured book on the Leanpub homepage! leanpub.com cc @ztellman

The tick's model of its environment cannot guarantee a consistent outcome. For any given values of heat and sweat, there are scenarios that lead to success and scenarios that lead to failure. Nevertheless, the tick survives; its simplistic model satisfices.

Consider how the world is seen by a tick.

Self-consistency is necessary, but not sufficient. When evaluating software, we cannot ignore the broader context. We must take advantage of every available perspective. We must be dissatisfied with easy answers. We must be curious.

There are countless resources for creating self-consistent abstractions, but few for creating useful abstractions. This is in part because self-consistency is an objective property, while utility is hopelessly subjective.

In software, we don't have the luxury of ignoring context. We need our models to be self-consistent, but we also need them to be *useful* within our given environment.

Hoare's abstraction function, like the Church numeral, is a mathematical abstraction. It describes a model which has provable qualities and is often described as "correct," which means it is self-consistent. By omission, it deems the context unimportant.

But the cons cell is not timeless; since its invention in the late 1950s, computers have changed. Notably, processor speed has improved more than memory latency, and so the relative cost of following a reference has grown over time.

For a table to be useful, it must avoid conflicts. One way to accomplish this is to keep the table private so it reflects only our vision of how keys map onto behavior. Alternatively, we can extend the table using only private keys so no one else can shadow our behavior.

A reference *conveys* values, and a conditional *decides* based upon values. These are complementary primitives and are present in every modern language. Through their composition, we can create software of arbitrary complexity.

A name is a lexical reference that is dereferenced at compile time. A pointer is a memory reference that is dereferenced at runtime.

Indirection provides separation between *what* and *how*. It exists wherever "how does this work?" is best answered, "it depends."