This masto thread should resonate with folks here. Teaser:

fediverse is the kind of place where I can ask a question of “let’s say we’re designing an operating system from scratch. Clean slate. Let’s throw away all our old habits and legacy decisions. what’s the minimal set of applications we need to make a new operating system useful”

and the top replies are vt100 emulator, virtual machine to run other operating systems, and c compiler to port vim

like y’all are missing the point of the question!

Reminds me of a similar question to some of the top economists, "if we could redo our tax system from scratch, how would that look?" They all basically said, its good the way it is, doesn't need change. I think there are several forces at play: "You don't know enough, so you feel like all this complexity is unnecessary" "You know all the details and lost the big picture", "You have stakes in the game" "You resist change" "Something out of the ordinary does not get funded" "The idea, actually just adds to the complexity" "There is no transition from old to new" "The new idea is just bad"

If you look at a complex system that has evolved out of thousands (millions?) of little decisions over a long period of time, and then ask to redesign such a system from scratch, it’s just overwhelming. There are no good answers to the question, because all the answers we have found in the old system came out of this long grinding process. To answer the question, we’d have to go on another long journey of making thousands of little decisions one by one all over again. I bet if we tried, we’d end up somewhere completely different this time. But it’s hard to convince people to do it all over again. Seems so inefficient. But if you see it (oversimplified) as a binary decision tree of 1000 decisions made over time, it would be rather spectacular if we nailed each of those 1000 decisions the first time such that we would take exactly the same path again.

The path depends on the ongoing context as well. What specific hardware tech is available and feasible. What ideas click and get funding, or get picked up by a business that happens to take off due to market factors.

If you look at complex social systems such as tax rules, big changes happen only after some major breakdown: after wars, revolutions, etc. Inversely, accumulated unsolved problems are the cause of such major breakdowns. The interesting fundamental question thus is if complex systems can undergo major change in an evolutionary rather then disruptive way. I don't know the answer. In a well-delimited technology context, starting from scratch is a realistic approach in a research setting, but not in real-life applications. Research projects of this kind can then influence the evolution of mainstream tech. That looks like a reasonable way to evolve rather than disrupt working systems. An underappreciated concept in this space is the narrow waist (https://www.oilshell.org/cross-ref.html?tag=narrow-waist#narrow-waist): a system layer that permits independent evolution both above and below it.

Isn't the "narrow waist" part of the problem and not the solution? One could argue that CPU <-> GPU divide is a narrow waist. Both are developed independently, but at this point we're really putting a smaller supercomputer into a bigger computer. The communication between the two is a big source of complexity in todays compute.

I have also been struggling with the “narrow waist” concept. I’m not entirely sure how to properly distinguish it from or how it interacts with layer architectures (which seem to be the primary example) and separation between interface and implementation. There is something important all of these point at, which has to do with stabilizing one part while allowing another to change. But the distinction isn’t as clear as they all make it look. The description I like most so far is the one Herbert Simon makes in The Architecture of Complexity, where he talks about “nearly decomposable systems”. That seems to capture the not quite clear boundary between what can change and what is stable best. And I have a suspicion that there is no clear boundary that can be drawn, and that the subtle interactions between different scales, what makes Simon call it nearly decomposable, are actually not a bug but a feature.

stabilizing one part while allowing another to change

Question: Is the /bin/sh pipe operator

|

a (restricted) form of narrow waist?

In a well-delimited technology context, starting from scratch is a realistic approach in a research setting, but not in real-life applications. Research projects of this kind can then influence the evolution of mainstream tech. That looks like a reasonable way to evolve rather than disrupt working systems.

Indeed. Any foc style work or ideation we do should completely ignore the status quo for this reason. I feel if you think about product-market-fit you've already lost. Depends on your goals of course, I'm taking about research.

@oPOKtdJ4UbTdPaZig6jg I wouldn't call CPU/GPU a narrow waist. CPU and GPU are not different technology layers. CPUs are not implemented in terms of GPUs, nor the other way round.

Now I'm rereading https://faculty.sites.iastate.edu/tesfatsi/archive/tesfatsi/ArchitectureOfComplexity.HSimon1962.pdf I swear, sometimes I think I only read the first 5 pages of any paper. I very often have no memory of the rest.

A good example of a narrow waist is in the internet architecture. TCP/IP is the waist with heterogeneity and evolution both above and below it. I believe the concept of a file is also a narrow waist. Not only do you have different filesystems underneath, you can also map it to different mediums (SSD, HDD, optical, remote). Of course there is the entire world of applications above it.

Ok, I'm gonna do one more comment on the subject of how come I don't remember all this from The architecture of complexity. Hopefully it's not too off-topic. In 2 pages from page 8 to page 10, the paper makes the statement that I think Stefan was pointing at above: • When subsystems are out of equilibrium, you can ignore macroscopic interactions between subsystems. They're in the noise compared to the churn going on within each subsystem. • When subsystems are in equilibrium, cross-subsystem interactions dominate. You can even summarize each subsystem with a few gross aggregate metrics. This duality is really interesting! It connects up with Christopher Alexander's A City is not a Tree (https://www.patternlanguage.com/archive/cityisnotatree.html) However, in the rest of the (17-page) paper Simon focuses exclusively on the second bullet. The result is to belabor something we moderns at least get told all the time: to manage complexity, divide and conquer. This is why I totally missed the gold. I think I'm saying I appreciate @Stefan for highlighting this point almost more than I appreciate Herb Simon 😄 Perhaps an alternative explanation is that Herb Simon had several thoughts on the subject and put them into a single paper. If so, a unitary introduction and conclusion feels counter-productive. This is a series of short stories, not a novella.

@shalabh That’s the example I had in mind. So, ok, if that’s a narrow waist, then is, say, LLVM also a narrow waist (between compiler front- and backends), or is that something else?

Yes LLVM is also a narrow waist.

@shalabh Thanks, that makes sense. Now I’m wondering: What would be a good example for a layer architecture that doesn’t have a narrow waist?

Layers are essential to narrow waist but not vice versa. I create systems all the time with layers, but no special narrow layer that has diversity above and below. I have a web app handing request above and an db access layer below, with an actual db underneath - it's like a cylinder. There are no ecosystems involved. You can say libraries like sqlalchemy orm try to do a narrow waist, but have not been as successful. The leaky abstraction principle also applies - some waists work better in their context than others.

Sounds like layers can have two purposes: • 'vertically' to separate concerns • 'horizontally' as a narrow waist

@Kartik Agaram Thanks. I found the room temperature example useful to illustrate this. Simon also points out in that paper that it’s not quite clear if we see hierarchies everywhere because they are everywhere, or just because we are adapted to see hierarchies. That’s also pretty much just a sentence or paragraph at most, but in my view one of the most thoughtful observations in there. I’ve mentioned Alicia Juarrero somewhere here before who wrote two books that take this idea of interactions across subsystems on different hierarchy levels much further with a comprehensive theory about constraints. In case you were looking for another rabbit hole… :)

Kartik - I didn't get the vertical vs horizontal - can you elaborate / give an example of vertical?

@shalabh I was imagining the layers stacked one on another. So as you move vertically you cross layer boundaries. Imagine you have a system. As you separate concerns it's often natural to have one concern treat another as a black box. Caller vs callee. You're basically creating a layer boundary here. So this is what I think of as 'vertical'. But another reason to create a layer doesn't start from a system at all. Instead you have a bunch of systems of two kinds that want to talk across a requirement/provider boundary. I imagine these alternatives lined up horizontally in two lines, one above another (but here 'vertical' doesn't mean caller-callee, hehe. It's symmetric; either side can initiate a connection). In this case you form a new system "fully formed from the brow of Zeus" as it were, to intermediate the two sides. This is the thin waist. Before it existed there was cacophony. After it exists you suddenly find yourself in a layered architecture.

yeah makes sense. "interoperability standards" often seem synonymous with narrow waists. it's not about a single system but an ecosystem.

@Konrad Hinsen About Simon’s approach: What do you mean by “rarely adopted”? Simon was trying to describe and explain complex systems. I’m not sure there was anything to adopt? I think his observations do apply to layer architectures. First, in the form of leaky abstractions. But even if the interfaces are well specified and achieve good separation, which is incredibly difficult to achieve, there are still subtle effects that can be ignored most of the time, but then sometimes do shine through, like, I don’t know, packet size constraints on the IP layer causing performance issues on the HTTP layer or something like that.

@Stefan I meant rarely adopted when designing software systems. Simon's discussion is about both natural (evolved) systems and about human-made artifacts (and he says it's for the same reason of economy in construction). His artifact example, a watch, ends up made from nearly decomposable subsystems not through insight into complex systems, but because watchmakers are clever people and end up designing watches in a way that is easier for them to build. In software, I don't see this happening. On the contrary, it is very difficult to achieve such a design, because our toolboxes are set up for strong coupling of submodules via shared dependencies.