If you are looking for a little more background on what this is all about, I’ve collected a few good resources in this short Twitter thread: https://twitter.com/stefanlesser/status/1312739694950612993?s=21

@Stefan do you know how many of the 15 students have background in architecture vs software?

(I'm technically still on leave from this community, but just happened to actually peek at the latest weekly email, and I saw this thread and just had to jump on, and this is a very specific opportunity I'm working to make a singular exception for ... Side note, making progress managing ADHD ... despite that one 3 hour recording 😅😬)

i feel like a lot of us participate asynchronously so any way to learn that's friendly to that would be 👌

dont let me oblige you to take a bunch of notes for us though 🙂

Anyone else doing anything similar to what any of these articles describe?

@Stefan 1. Your last paragraph really resonated with me as being what software really is / can be, as a medium. 2. Design Patterns in software are actually a horrific failure of an attempt to capture what Pattern Languages in architecture were fundamentally about. I'll explain: Design Patterns (if software was a building) are more like solving very particular (and invented) problems with the electrical wiring or plumbing, or building a wall with a limited supply of wood beams, etc. Nevermind why the building is being created in the first place (e.g. as a place to live, and therefore as a good place to live). Pattern Languages are about shaping (and solving problems for) the human space within it. For example, an entrance transition because "the experience you get leaving and entering your home influences the way you feel inside it". Nevermind how it's otherwise literally constructed.

I think Christopher Alexander's work is about about understanding a thing not in terms of the thing itself, but of the environment that it creates for those using or inhabiting it. A building (as a place) is not the building, it's the human space in between. A software application is not a framework of code or services, but the experience it creates for, say, booking a trip. Even words used to describe software take on new meaning if thought of this way: robust, elegant, connected, intelligent, clean, efficient, flexible, adaptable, innovative, disruptive, functional, dynamic, correct, agile, powerful, "best practices", etc.

Here are my initial thoughts on the relevance of Alexander's method to programming language design. More questions than answers. Every large software project can benefit from having a pattern language to direct and coordinate the development. "Large" means: multiple contributors, with the need for coordination between contributors, or, a single person project with enough code, written over a long enough period of time, that you can't keep all the details in your head. My Curv project has a pattern language, but much of it is implicit knowledge. It will be beneficial to make that knowledge explicit, to write it down. It will speed up development by making it easier for me to make design decisionsand engineer past roadblocks. And it will make it easier for other people to contribute to the project. Curv, as a programming language, has an ASCII text syntax. Part of the pattern language will deal with centres, activities and patterns relating to that syntax. What gives "life" to a language syntax? Curv is also a development environment. The project's pattern language will deal with the developer's experience of using Curv and its associated associated development environment to create, run and debug software. What are the related centres, activities and patterns? And there is a meta level. Curv is used for software development. Part of large scale software development is creating a pattern language for your project. How does Curv help developers create and use a pattern language? What are the patterns for that? In formal language theory, a language is a vocabulary and a set of grammar rules which recursively unfold to generate all the valid sentences or utterances in that language. We use these same ideas of generative grammar to design and think about programming languages. Alexander's method seems to be inspired by generative grammar, because he talks about recursively unfolding patterns to generate architecture. So what does this mean for the links between Alexander's method and programming languages? Can do you design a programming language's vocabulary and grammar rules so that they recursively unfold to generate living structure?

Oh, that’s funny: just going through other unread threads here I found this one, and it seems to be a good example of what I was just trying to describe: https://futureofcoding.slack.com/archives/C5T9GPWFL/p1604697998353700

In the meantime I also wrote a quick draft with a higher-level collection of various ways on how to adopt Alexander’s ideas; what we just talked about above being just one of seven things I could think of (I’m sure there are more): https://stefan-lesser.com/2020/10/27/how-to-adopt-christopher-alexanders-ideas-in-the-software-industry/

David West's web site looks like a good place to start: <http://davewest.us>. He is writing a book called "The Design of Living Systems" which sounds very Alexander-inspired (no summary is provided, just the title). The newer book "Design Thinking" also looks very Alexander inspired--table of contents mentions living systems, form, fit and unfolding. This book is also not available yet. However, there are online papers and videos, including "Conversations with Alexander". So I'm going to dive in now.

Another problem with OOP is that it is fundamentally based on shared mutable state. You system is composed of objects, each of which has an identity and mutable state, and you compute by sending messages to those objects, causing them to change their internal state. Shared mutable state is the source of massive complexity in software systems.

So I want a better programming methodology than OOP, one that has very good support for modularity, simple abstract interfaces, composable software components. The solutions I'm looking at are related to functional programming. Instead of mutable objects, you work with immutable values. Instead of "Object Oriented Design", I'm learning "Algebra Driven Design", where you consider a type (a set of immutable values), together with constructors for those values, and operations on those values, as an algebra. You work out the equational laws that relate these constructors and operations, and that gives you the abstract interface and the semantics of your algebra (which is a kind of module). My experience so far is that this design methodology can produce simple, elegant and powerful interfaces that have a quality of "life" that I would not be able to reproduce in any other way. I found the book "Algebra Driven Design" to be helpful in learning how this works.