One thing that's great about C.A.'s work / philosophies, is not just that it ties mechanism & structure to things like life and purpose and well-being, but that the links are more than just nice ideas; they are verifiable, and consistent. There is a very real link between technical goodness and moral goodness. The properties that make living things "alive" work the same way in built things as well. Etc. These "real connections" (I'll call them that) between seemingly unrelated areas & concerns, show up everywhere! It's why I've taken sudden interest other areas where this crops up: built architecture, urban planning, interior design, etc. What I've noticed is that much of what is wrong/missing in software, is actually part of a larger problem that affects many facets of the modern world. And, by finding solutions and patterns in other areas, we can improve software (or use software to improve the world) in similar ways.

An example principle is that the best way to create a "good" "place" is by fostering an open, communal, trusting, and humane environment, and not by forcing, restricting, and securing. ("Good" can mean safe, productive, adaptable, etc. "Place" can be a home, community, workplace, or even software code). Jane Jacobs (an urban planner) noted this: fences, private corridors, locked doors, people keeping "safely" to themselves, increasing police presence ... these things raise crime and isolation and danger. Openness, communal exchange, visibility, etc. create more security and enhance life. Part of that is related to people feeling like they "own" a place psychologically and emotionally, which creates a community that automatically keeps itself safe and comfortable. Etc. The corralary with software code is that you can NOT create "better" code by relying on mechanisms that lock down and restrict. Better off creating an environment to encourages openness and trust; code that is "habitable" and a happy place to "live" in. After all, good software is about understanding the human model and making THAT as good as it can be, with the mechanism only in service to that end. Linda Rising explores that connection between this "Quality without a name" (as C.A. calls it) in the real world, and in software: https://www.researchgate.net/publication/265427581_The_Road_Christopher_Alexander_and_Good_Software_Design

On the topic of (what C.A. calls) "Living Structure" and bootstrapping: I (and others here) have determined that part of the problem with the way most software is created (and its usability) is that it's very rigid and locked down. I see common themes of code being made of actual structure that can be manipulated directly (versus text); removing the separation between code & data, or between the thing being created and the tool used to create it, or programming language and program, or language and tool/UI. C.A. describes the modern way of building and designing things as trying to find a good configuration (e.g. a blueprint, or model, or business requirements), and then creating the thing from that rigid form. The result is never "living structure" (e.g. cannot be properly adapted to unique contexts and needs, and cannot evolve as those things change). In contrast, he suggests a process of "unfolding wholeness", where a thing evolves step by step directly in the context where it is to be used or occupied. It is "whole" at each step, and differentiations are introduced gradually to fit the context. This is in stark contrast to mass production of modular units, for example. Applied to software, this means that the tool, or the model, or the design process, or whatever, must evolve with the software (perhaps even with the user), otherwise you are left with something rigid that cannot perfectly fit the context. Essentially, I'm drawing a parallel between "unfolding wholeness" (aka structure preserving transformations) and bootstrapping. And not just bootstrapping a language, but also a tool, a UI, ... everything. All things that can be called "living structure" exhibit such properties. So, the ability for software to be created and manipulated as "unfolding wholeness" through structure preserving transformations (e.g. extreme bootstrapping at all levels) ... This is key to creating the "living structure" that software can be. Both as LS itself, and also in that it can be used to create LS -- that is, people can create whatever they want, however they want, have it for the context uniquely ... and that also has strong implications for changing the way that the modern world functions as a whole. So the potential for living structure is enormous ... And recursive! C.A. identified that recursiveness, too. In all living structure, there are things called "centers", which are essentially defined as connections of other centers that form a stronger whole center together. The livingness (or wholeness) of any center is recursively dependent on how alive or whole it's inner centers are. Living structure, is made of living structure. And living structure can only be created by/from other living structure. So back to programming, this means that in order for code to be living structure, then even the tools used to make the code need to be living structure. And if you want software that can be used to create "living structure" in the world, then that software itself must also be living structure.

(continuing from previous) Now this is all true of literal living structure -- living organisms. There are multiple levels of wholeness / centers: systems, organs, all the way down to cells. At every level, these are said to be living and whole, and can only be so because they are made of smaller living wholes. You are not your cells, but each individual cell can be considered to be "alive" and whole. But within the cell, there are whole things, which -- through an unfolding (iterative) process -- produce living structure (both because they constitute it, and perform processes that create it, and also cause it to function). Think of it: everything the body needs to function, or grow, or adapt, or generate new life ... It's all part of the body itself! The same is true at the cellular level. The cell contains all the mechanisms and processes it needs to bootstrap itself. There is debate about what does or does not count as "life" -- particularly, are viruses "alive"? Isn't it fascinating that the determining factor is that they do not contain everything they need to be self-sufficient / self-generating? Unlike "living" cells, they are not "whole", because they rely on external means to make them "alive". ... And yet, they do manage to do things, and regenerate themselves; isn't that alive? ... Well, it's the living structure in other cells that causes that to happen. They are not whole, and not wholely alive. At the least, it's fair to say they contain (or are themselves) bits of living structure. Programs are like viruses. They contain/are the "code" (DNA) for a process, but they do not themselves contain the machinery for running, duplicating, and modifying that code. You need an editor, a processor, a compiler (ribosomes, enzymes) to do those things. And those things (complier, editor, etc.) are not alive either, because they also rely on others tools to be created or modified. So what would it mean for code / software to be "alive" or counted as "living structure" -- and why does it matter?

(continued from previous) ... It would mean that a program (or other software entity) contains all the mechanism needed to edit, view, run, and replicate (e.g. generate or serialize) itself. For any software artifact (e.g. a game or a drawing or a document), you are limited by what some tool let's you do. You can either accept that, or pick a different tool, or painstakingly invent a new tool ... which still leaves you stuck as before, albeit with different features. But if the thing is its own editor and modeler and viewer, etc., then you can use it to change itself, and adapt it to fit your needs. As you make changes to the tool-in-the-thing, you also gain the ability to use the new changes to keep making more changes. There you have unfolding wholeness, and structure-preserving transformations. The idea is that there then becomes no excuse to not have the most (or at least, reasonably) ideal tools, visualization, structure, etc. for whatever. Now the point is not necessarily for some software artifact to be fully moldable (cool, but so what?), but to make that power accessible so that software can be used in new meaningful ways, perhaps to change the world (e.g. ability to create the world we want to live in ... technologically, but also socially, mentally, etc.)

What all that in mind, have a look at: * His address at OOPSLA '97: * This (very cheesey, but good) video (especially how it correlates to software at 11:15 - 14:45):

More on "patterns": What the software world calls "Design Patterns" are directly derived from C.A.'s "Pattern Languages". However, they completely missed the boat as to what patterns are about and where the focus should be. "Spaces for the soul" from 14:45 - 15:35 (second link in previous post) highlights the overlap and the difference: We got the "solving common architectural problems" part, but missed the part about those "architectural problems" being about creating a structure or environment that best serves it's users -- it's not about the physical structure, but the spaces between the walls, and letting the patterns of events and interactions of it's occupants be what shapes it -- because that is the architecture (e.g. a place to gather, a place to eat, a place to work -- asking what kind of "place to _" would you like to live in, and then building it). It's not about the structure, the structure is just an outline of the important stuff happening in that space! And you might say "So what?" that DPs and PLs don't match. The fact is that it didn't start that way: There was a whole "patterns" movement on software with that intent, the remainder of which has survived as "The Hillside Group", which has been putting on PLOP (PLs of programming) conferences since then, which has more or less succeeded OOPSLA. So for example, some of us are interested in visual representations for software (as opposed to textual code). What if that meant a great way to visualize the interactions that I'd like to be able to perform as an end user? That could make software much easier to understand on both sides of the fence, and put that power in more people's hands. So imagine such a tool, and imagine a growing practice of identifying recurring patterns of events that "work" for creating good software -- "good" in the ways that matter. That's what "patterns" were about, and could very well be the future of software design.

Here's my YouTube playlist on Architecture & Design. Every video is somehow related to C.A.'s material, and can in some way be tied to software (try me): https://www.youtube.com/playlist?list=PLcxHi1cwstVD2d-qe0kn9XMjL7pdlzm1W

Richard Gabriel ("worse is better") actually had a lot to say about CA's work (notes, pattern languages, nature of order), and wrote some nice essays / slides about it that might be more tractable than reading through all CA's books, which you can find under "Essays" on his site: http://dreamsongs.com He also has a lot of other things to say about the design/art side of programming, and was one of the founding members of the Software "Patterns" movement (Hillside Group) from which software Design Patterns (d)evolved