Short thought this time around. When designing languages, we have the “how it looks” part (syntax), and the “what it means” part (semantics). What it means is often the same as “what it does” or “what it evaluates to”. For the simplest systems, the two parts are fairly close together: in term rewriter systems, the most you can expect something to do is to replace some sequence of terms with another and call it quits. These systems usually have a very simple syntax (couple of symbols) and a simple semantics (couple of rules to transform the syntax into other syntax), and yet they turn out to be able to represent arithmetic operators, sets, other systems or all of the above. The discussion I mentioned is about exactly this: Where does this ability come from?
In a few words, abstraction seems to fit the bill. We allow symbols to abstract for more complex flows, and in doing so multiple times, we build layers upon layers of implicit state that we can willfully “forget”. In this sense, abstraction allows for increasing the output of our system by shortening how many things we need to say to make things happen.
Upon deeper examination, however, there’s a layer of term rewriting that happens in our minds, powered mostly by intuition, pattern matching and substitution, that lets us reason between two established systems that we know – what we write and what we want. The main difference between this and the previous explanation is the placement of the layering: yes, we can add layers to our programming language, but in the end, there’s always at least one layer that lives fully in us. We are the middle-ground there, and the actual transition happens there. This is the difference between someone who sees the input, the output and the transformation between them and understands it, or doesn’t. In this view, it seems less about abstraction, and more about liminality.
In the book “Holonomics: Business Where People and Planet Matter” by Simon Robinson and Maria Moraes Robinson, the authors speak about liminality with regards a new way to think about businesses, people, and the world. This holonomic way of thinking is described as a dynamic way of understanding relationships within a system. It sees the ever-present complexity and chaotic nature of the world (seen through economics, business, etc.) as the foundation of successful structures instead of a fear factor that leaders should fear coming into contact with, allowing for a more sincere approach.
Most interestingly to me, it gives this diagram:
The authors are explaining a transition to holonomic thinking and why it is required for a better tomorrow and a deeper understanding of the business world. They describe three ways of thinking – mechanistic (where we focus on objects), systemic (where we are working with relations), and holonomic (where we focus on meaning).
If we squint, we can see that this diagram is familiar: objects are the symbols we use to write code, meaning is a literal meaning of the word “semantics”, and indeed – between the two we have layers of interpretative relationships that both transform and build state.
In the figure above there is a dotted line which represents a wall, a barrier beyond which many systems thinkers do not go. It represents their inability to break out of their mechanistic world views; it is ‘the point of liminality’. Liminality can be thought of as a human type of singularity point in a black hole, a halfway point in transition, where existing structures have broken down but new ones have not yet been built.
Simon Robinson and Maria Moraes Robinson
The threshold of liminality is not only the space where the “a-ha!” moment lives, or where good ideas become best when left alone for a while, it’s also where we, as programmers, live. Being comfortable at the threshold of liminality allows us to abstract and generalize as much as we do.
This idea would finally explain why we’re so bad at finishing projects as well – going outside the threshold of liminality, and even the whole domain of relationships, feels like losing degrees of freedom. Objects feel non-interesting, meaning seems implicit, and the will to spend time in these non-liminal spaces is fleeting. To finish is to give final meaning to final objects, and after living a life in the backrooms, there are only so many more difficult things to do.
Of course, not all programmers are the same, and this is good. We all touch these domains in different ways. There is the C programmer, a solid cylinder that phases through the whole space – from objects to meaning and straight through the threshold of liminality, cutting through them with full domain knowledge and zero confusion but a limitation (and even dislike) for high-level abstractions; there is likewise the Haskell programmer, a 4-dimensional toroid that barely touches objects and barely touches meaning, and has made a recursive den within the liminal threshold.
Leave a Reply