A book by @ztellman about the philosophy of software, through the lens of Clojure

Joined July 2018
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/…
1
5
1,148
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/…
1
1
1
1
1,758
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/…
2
737
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".
1
4
1
15
2,516
Elements of Clojure retweeted
I wrote about why coupling has an unfair reputation in software design explaining.software/archive/…
5
19
2,137
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/…
4
9
1
57
5,334
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.
Earlier this year I went part-time at Microsoft to work on a new book, which will cover many of the same topics as Elements of Clojure, but more clearly and completely articulated, and hopefully accessible to a broader audience.
4
13
6
95
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.
4
Consider how the world is seen by a tick.
2
1
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.
4
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.
1
7
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.
6
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.
2
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.
4
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.
2
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.
2
A name is a lexical reference that is dereferenced at compile time. A pointer is a memory reference that is dereferenced at runtime.
4
Indirection provides separation between *what* and *how*. It exists wherever "how does this work?" is best answered, "it depends."
2
8