Interesting, I think. So the key difference with Kolmogorov complexity is that it's computable, right? It seems like a special case Kolmogorov complexity but with a weaker programming language that doesn't have all it's interesting properties locked away by the halting problem.

Looks like it has found application in studying the chemical origins of life, where the only operation for creating complexity is just sticking molecules together. That makes sense. But it's pretty limited. Like I don't think it can detect the regularity in a bit-string like 101001000100001000001...

Reminds me of Minimal Description Length , which is also an approximate-but-computable variant of Kolmogorov complexity.

I love the source being pulled from here and agree with the ideas. I would add that I think work by philosophers on conceptual engineering is definitely relevant to the project.

What I honestly don’t get is the conclusion. I don’t get why we would want to start talking about structures or patterns in code.

I consider codebases to be more like painting than literature, in that they are non-linear. They is no preferred reading point for a codebase. Main may not exist and just because there is an execution point, it does not mean there is a reading starting point.

When we examine paintings we do look at elements utilized, we can talk about style, but we also focus on the particulars of the painting. It’s historical situatedness. The artistic landscape in which it lives. We give a description of the painting not necessarily as it is, but as it appears under a certain interpretation. (Giving a description of the picture as it is would just be to list its “pixels”. We instead want to hear less precise words like energetic, placid, disturbing, etc. )

In the same vein finding the archetypes, structures, patterns, whatever you want to call them ignore this particularities of software. It ignores their historical moments. It ignores that we create programs not isolation but in response. That we choose structure not for their properties, but because of past failures with other structures.

We need analysis yes, but in order to do a history and critique. Software studies does fall quite short of this. There doesn’t seem to be people deeply embedded in our culture doing that work. Instead we get an outsiders perspective. What I would instead want to see is a deep analysis of code that reads out the implications of the structure. That looks at the beliefs of the authors. That sees the conflict as the code is produced. That followed the influences. That draws out theories. That show us the shortcomings of the path that we are on. That calls us to higher ideals.

We don’t need a guidebook. We don’t need a catalog. We don’t need anything that helps us code. We need something to help us reflect, something I believe we are in general as a culture quite bad at.

Haha was just gonna cc you! Thanks for the response, i like the framing. I was wondering if you could expand on what you mean by “reflect” and why its not a commonly transmitted value in software culture?

More as in reflecting by slowing down the process of developing software as a means to be more thoughtful? Or as in studying and learning about history?

I think about our lack of reflection in two senses. First there are no great works of meta-software creation. We have Naur’s programming as theory building. But that is a short paper that hints at ideas. We have no work that explores our discipline at depth the way other fields have philosophy of x or methodology of x. So as a field we haven’t reflected enough.

But the way I used it in that last sentence is slightly different. We as individual programmers don’t reflect enough on our own practice. We might think about best practices, we might consider how to solve problems we have, but we don’t spend a lot of “armchair time”.

Even if we aren’t the ones coming up with great answers to these difficult questions, we need others to help us think more deeply about them. What exactly is an abstraction? What is the nature of a program? Why have we privileged some features of nature language in our programming language and denied others? Can our programs have meaning outside of what we intend then to? Where do they get that meaning? What do we mean we talk about an explanation for a bug? When is a reductive explanation if a bug useful and when is it not? What does that tell us about explanation?

There are so many questions we ought to sit and ponder. We are a culture that is good at arguing about things that honestly don’t matter much. And bad at asking fundamental questions and considering answers to them.

I have some not fully formed ideas about why this lack of reflection has happened in our culture. First is a deep seeded implicit belief in positivism that so many programmers hold. We often believe that only measurable scientific things are meaningful and so dismiss philosophy.

But I also think this lack of reflection comes from our frustrations of the kinds of work we have to do day today and yet the realization that we have it pretty darn good. We have great job security and great pay. But the software we are forced to make is terrible.

In this environment, deep reflection does not help us at all. It just reminds us how shallow our work truly is. Instead, we constantly try to find ways to feel our work had more meaning. Hence to following if trends, the gatekeeping, and the tribal behavior.

I don’t think we need to slow down the process of making software. Just that we need to care about the “non practical” questions of our field. We need to think much more deeply about the work we do, think kind of work we want to do, and the nature of our work.

As so often, I wonder to what degree this discussion is related to the abstraction level of the concept "software".

In my field of work (research in physics and chemistry), there is a long tradition of reflection on our work practices. At the extreme, a few physicists end up writing books about this reflection (such as this one, which is very good but a bit old by now). Away from this extreme, discussions about our methodology happen all the time, be it at lunch or at conferences. And since nowadays we all use computers, the use of software has become part of this discussion. But we don't discuss software in the abstract, we discuss the creation, maintenance, and use specifically of the software we use.

Jimmy Miller Exactly as you say: we need to focus on the “big picture” view of a given program, in order to reflect on its constitution/composition/architecture and employed methodologies.

But I can’t see why you think this is antithetic to focusing on structures/patterns embedded in the code? I think it can help; it’s the first step to understand the program. Of course, this assumes that the primary goal is utilitarian (the program should work). However, I think this comes hand in hand with the more “aesthetic” appreciation of software.

I don’t know about other people, but two properties of (some) programs I find very beautiful is emergence and reflectivity . In other words, the fact that a composition of a few simple programs can generate complex behaviour, and that there are (many) programs generate a whole new world inside them (and that they’re embedded in these worlds). In most (all?) “art heavily depending on software”/“software being art” I’ve seen, it was especially emergence that “made it artistic” (I’m not counting surface design).

As one quickly realizes, these two properties make software very complex, so in order not to be stuck just blindly experimenting, one needs to employ some tools to understand programs (and finding structures and patterns is the most basic form of that; it shouldn’t be overlooked).

(Blind experiments can be good (to test the boundaries of the current theory), but imagine composing music just by pushing random keys on the piano. That’s no way to be much productive, even artistic. Without (music) theory, there would be no Bach.)

Structures could provoke someone to reflect. I just don’t think they will given our history with them. Structures can also be a shortcut. A way not to have to think. Instead we can rely on the structure as a substitute for understanding. I think this is exactly what we’ve done with patterns and why they’ve failed both in software and in architecture.

I love your description of reflection and emergence and if this were the level of specificity of structures imagined I’d be all for it. But it seems from the talk (which I did attend in person and got to briefly talk with Zach afterwards about) that the imagined discussion is much more practical and hands on.

Honestly I just find structures as proposed a bit boring. What is interesting to me about software is less what various programs have in common and more about the particularities of a program. But also what isn’t in the program proper. What is in between the lines.

Finally I will say I think there is a vast over emphasis on interfaces and I perhaps am reading into this that same emphasis. I think interfaces are some of the least interesting things to consider in programs and our over-emphasis on them has caused a lot of bad styles of programming.