
A book by @ztellman about the philosophy of software, through the lens of Clojure
Joined July 2018
- Tweets275
- Following1
- Followers926
- Likes12
Elements of Clojure retweeted
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/…
Elements of Clojure retweeted
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/…
Elements of Clojure retweeted
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/…
Elements of Clojure retweeted
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.13…. There, they defined relationships inside functions as "cohesion", and every other relationship as "coupling".
Elements of Clojure retweeted
I wrote about why coupling has an unfair reputation in software design explaining.software/archive/…
Elements of Clojure retweeted
I wrote about the three-part structure of explanations in software development: explaining.software/archive/…
Elements of Clojure retweeted
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/…
Elements of Clojure retweeted
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 retweeted
Elements of Clojure leanpub.com/elementsofclojur… 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.
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.


