Saw him speak at Berkeley around the time his book on the Eshin project was released. Talked in very strong terms about the importance of working in a holistic, caring way.
A SWE in the audience spoke up, saying basically "look, we want to follow that approach, but it's hard, we have a lot of stakeholders to satisfy in order for a project to happen."
Alexander was unyielding. "Once you've worked with love, you won't want to work in any other way."
YMMW on the practicality of his advice, but it was super inspiring.
Without knowing Alexander's concept in detail, once I learned to work (and live) that way, doing otherwise has seemed like a waste of time, almost pointless. The only point is that, unfortunately, many people don't understand - and scoff at - working 'with love', but in those cases I often feel like I'm mostly building a road to nowhere.
I once had a high trust (love) team. We kicked ass. Together. I miss it every day. Everything since has tasted like ash. I've been trying to get back to that happy place ever since. Sadly, I eventually stopped talking about trust (in the workplace) IRL; people don't much like crazy talk or zealots.
I've been on a number of teams like that, and miss them. There's a phrase 'the song of friends at work' that I can't find the source of, but it serves as a kind of navigation point for me as I try to steer my career and efforts.
This is the reason I changed how I approached software projects. Alexander made me rethink how software should be built: with love for the user, but also with love for other developers.
Adjust your own mask before helping others with theirs.
It always appalls me when developers reason that a software development system that barely functions for themselves will somehow result in an application that the users will enjoy paying to use.
Software that doesn’t work for the developers will eventually stop working for everyone else too.
> This is an extraordinary vision of the future, in which computers play a fundamental role in making the world—and above all the built structure of the world—alive, humane, ecologically profound, and with a deep living structure. I realize that you may be surprised by my conclusion. This is not what I am, technically, supposed to have been talking about to you. Or you may say, Well, great idea, but we're not interested. I hope that is not your reaction. I hope that all of you, as members of a great profession of the future, will decide to help me, and to help yourselves, by taking part in this enormous world-wide effort. I do think you are capable of it. And I do not think any other professional body has quite the ability, or the natural opportunity for influence, to do this job as it must be done.
>"Once you've worked with love, you won't want to work in any other way."
Interesting quote. It really makes me think about the great resignation and WFH movement. I think lots of people truly were asleep to how bad their job and consequently life had become due to working with all the negative corporate aspects of America. This is a succinct way to describe the trend.
I wonder if we will see drops in pharmaceutical and alcohol sales in the coming years.
I wouldn't call it love per se, but it certainly does take a special kind of empathy to put yourself in the shoes of someone using your software, and to use that perspective to make a great product.
Alexander advocated getting the people who would live or work in the buildings involved in the design and construction of the buildings. Get the people who will live in the place out in the field and work together to peg out the outlines of the buildings & refine the design.
This philosophy is succinctly summarised in the book Peopleware:
> local control of design by those who will occupy the space
Unfortunately this aspect of Alexander's philosophy of letting the users participate in the design, construction or customisation of building and towns was ignored, while the other idea of design patterns became very popular when adapted to software.
Some software is built for a market where the buyers are the end-users to software. Other software is built for markets where the purchasing decision is made by a committee of stakeholders, perhaps excluding the people who will be the day to day users of the software. If you contrast the two in terms of usability, you can start to appreciate what Alexander was getting at.
It isn’t as if the tech was not out there, but we made a conscious choice to move away from user-participation platforms — Hypercard and Smalltalk among the examples.
Minecraft has some of these elements, and is why it is fun for people.
Arguably, Roblox is the largest scale example, though my understanding is that it is still not so easy that end users can really participate in creating their own designs.
I have several junior developers on my team who came from the customer success / support side of the business who grew themselves into developer roles. They typically have not only the strongest desire to learn & improve, but also the most empathy and understanding of our impact on customers & their livelihood.
I believe every developer needs to spend regular time in a customer-facing support role (if possible). They will learn much more clearly how difficult (or less likely easy) their product is to use.
Yes! If you can get somebody on your team that has worked their way up from, for example, a customer service contact center, they'll be immensely valuable. Just their insight on what customers love and hate about your product is probably worth their hire.
This was my path into software development! It's served me so well, now I want to figure out how to "recruit" future engineers from customer service teams.
The benefits would be endless, and they'd "cut their teeth" on solving crunch problems for themselves/their teams.
I think it's a long term obvious win. If you care larger, you avoid painting yourself in corners. See what really needs to be done, do just that and enjoy the harmony.
I worked in the ad industry for years and made good money doing it. I now work, unpaid, on a FOSS passion project.
What I would advise is treating each job as a college course which you also happen to be paid for. For me, this meant not allowing myself to become emotionally invested in the work, taking good notes about what I learned each day, and looking for a new job (typically with a raise) once those notes were sparse for too long.
He had really interesting computational ideas about harmony. From The Nature of Order (2002) “As architects, builders, and artists, we are called upon constantly—every moment of the working day—to make judgments about relative harmony. We are constantly trying to make decisions about what is better and what is worse…”
Following this, he published a paper on “harmony-seeking computation” as an approach to optimize “wholeness.” He identified 15 elements of wholeness in designs that might be measured, like the presence of coherent centers, strong boundaries, local symmetries or roughness/imperfection. He proposes that “the harmony that is sought in these computations is indeed what we otherwise call ‘beauty’. But the result of harmony-seeking computations are not merely pretty or artistic. In most cases, they are also better functionally and technically.”
Alexander, Christopher "Harmony-Seeking Computations." International Journal of Unconventional Computing 4 (2008).
I wasn't aware of this paper before now and am excited to read it.
The 15 properties of life were, I believe, his attempt to find the universal rules underlying the design patterns he described in A Pattern Language. I've long thought that most of those properties could be described algorithmically and was curious what sort of system they would converge to. I suppose nature is one easy answer, but it's not a very useful one.
The main thrust of Nature Of Order is that these 15 elements of wholeness are itself a quantifiable measure of life, of literally how alive a system is. Christopher believed you didn't design and build a structure and then fill it with life/humans, rather he believed the process of architecture was itself about literally increasing the life of a space. An architect's job was to recognize life-creating patterns and imbue structures with them.
He believed that a meadow with a river bend, an old willow tree and a rock to sit on below it was not a scene composed of living and non-living entities, but rather the arrangement of these entities (both internally alive and not) gave rise to a wholistic quantity of life in that space. Depending on where the rock was placed the space itself was more or less alive.
It sounds like a far out, "new agey" idea but I think he argued quite rationally that this framing of life makes far more sense than a binary determination based upon near arbitrary delineations such as sex, reproduction and consumption of resources.
Fascinating. Saw a paper pop up on one of my Semantic Scholar feeds just the other day with the title "Symmetry and simplicity spontaneously emerge from the algorithmic nature of evolution". Here's the link https://www.biorxiv.org/content/10.1101/2021.07.28.454038v2
“Harmony” was also the metric used for the first multi-layer neural network by Smolensky (1983). Then Hinton called it (free) “energy”—same metric with a sign reversal. Then, with Rummelhart, they compromised and called it “goodness of fit.” Same as Harmony. So, neural nets still optimize for Harmony, by another name. I find that wonderful, somehow.
Meh. The whole "wholeness" and "structure-preserving transformations" thing just sounded to me like he was describing a literal cell division algorithm. He even gave cell division as an example of structured behavior rules producing wholeness out of chaos.
And is cell division any less magical for that comparison? We still don’t understand it well enough to build with anything close to the robustness & scalability of biological systems.
Very early in my software development career, i was frustrated and sad that i wasnt able to progress due to a lack of comprehension of how software is structured from smaller sub systems. I didnt have any kind of mentor available to me, and I seriously considered changing careers. I naively assumed that good software was written by naturally talented people, and because I was having problems growing I was obviously not talented and therefore would never get improve (I was young).
Then i stumbled across “Notes on the synthesis of form” from some random internet recommendation.
Not only was this book a complete eye opener, it helped me to understand so much about what I was doing was mostly by accident, and that design should be purposeful.
The most important lesson for my fledgling mind though was that design was a process, and a process that improved with each application. That good software developers arnt “born”, they are self sculpted.
I still have that battered, note riddled, page corners folded copy of “notes” and I take with me on holiday every year to re-read. Its my most favourite book I’ve ever read. It fills me with such inspiration everytime I read it.
I’m very sad to hear of Christophers passing. I never got to thank him.
My intro to Alexander was also through Notes on the Synthesis of Form, though personally I found it to be really antiquated. Shortly after I found out he distanced himself from a lot of the design methodology work he did in the 60s:
>‘There is so little in what is called ‘design methods’that has anything useful to say about how to design buildings that I never evenread the literature anymore [...] I would say forget it, forget the whole thing.’
That's not to say the literature and was/is immensely inspiring, so much so that his name comes up within software engineering as much as it does within architecture.
He described this distancing from the methodology, and consequently what he considered the salient message, in a preface for a later printing of the book [0]:
> Today, almost ten years after I wrote this book, one idea stands out
clearly for me as the most important in the book: the idea of the diagrams. [...] I
reject the whole idea of design methods as a subject of study, since I
think it is absurd to separate the study of designing from the practice of
design. [...] No one will become a better designer by blindly following this method,
or indeed by following any method blindly. [...] In the process of trying to
create such diagrams or patterns for yourself, you will reach the central
idea which this book is all about.
I think this explains why Inkscape is my favourite piece of software :)
> There is a central quality which is the root criterion of life and spirit in a man, a town, a building, or a wilderness. This quality is objective and precise, but it cannot be named. [...] It is not only simpler beauty of form and color. Man can make that without making nature. It is not only fitness to purpose. Man can make that too, without making nature. And it is not only the spiritual quality of beautiful music or of a quiet mosque, that comes from faith. Man can make that too, without making nature.
> The quality which has no name includes these simpler sweeter qualities. But it is so ordinary as well, that it somehow reminds us of the passing of our life.
> It is a slightly bitter quality.
- Christopher Alexander, The Timeless Way of Building
"The more living patterns there are in a place -- a room, a building, or a town -- the more it comes to life as an entirety, the more it glows, the more it has that self-maintaining fire which is the quality without a name.
"And when a building has this fire, then it becomes a part of nature. Like ocean waves, or blades of grass, its parts are governed by the endless play of repetition and variety created in the presence of the fact that all things pass. This is the quality itself."
> The awareness of impermanence, or transience of things, and both a transient gentle sadness (or wistfulness) at their passing as well as a longer, deeper gentle sadness about this state being the reality of life.
I just buy a new copy of A Pattern Language whenever I see it in a bookstore, because I know I'm going to end up giving it to someone. It's one of those books you can confidently recommend to any curious, intelligent person, and it may change their thinking, or at least blow their mind, whether they find it useful or not. He was such an original thinker.
I'd be interested in any details on that, i.e. what the house is like.
One lightbulb that went off for me when reading his books was the pattern of "windows on 2 sides of a room".
I realized the house I grew up in was a big mass-produced rectangle with windows on the front and back. And since no rooms spanned the house front to back, that means that no room in the ~3000 sq ft. house had windows on 2 sides. (This is close to "McMansion" architecture but not quite)
Since then I've noticed people gravitate towards rooms with windows on 2 sides, and now I live in a apartment with many windows.
For better or worse I've lived on both coasts and everything is "economically optimized" there. In SF and NYC it's very common to see long skinny apartments that were split down the middle at some point in the last ~50 years, lacking windows. And it's also common to see very boxy and optimized new buildings, i.e. lacking architecture. They're optimized for density and not living quality.
I may be buying a house, but these requirements basically amount to extremely expensive, old houses of a limited stock. I'd be interested in any counterexamples to that!
That pattern goes together with “Wings of Light” which is specifically about avoiding deep boxes in favor of e.g. T shapes and other narrower wings that can let light in.
There's a small distillation of his principles in The Not So Big House, (bonus, it has photos). From what I remember, you want to design space so people move from dark toward light, light rooms from two sides, sleep area should be like covered nooks for feeling of security, stairs and halls should be wider, there should be views from one room to another ... A Pattern Language and The Not So Big House informed how we did renovations in our own home.
I'm glad I stumbled upon his books when researching design patterns early on in my career. His writing in 'The Timeless Way of Building' left a big impression on me, precisely because it didn't reduce building to a sequence of mechanical steps which are to be followed exactly, but allowed, even called for, gaining a deeper understanding for quality. It's hard to express, but he did a stellar job at it.
It's somewhat ironic that he is said to have laid the foundations of the design patterns movement which, I don't know when, must have taken a series of wrong turns to end up where it did.
Thank you Mr. Alexander for writing about these fuzzy things which dare to be named.
> the design patterns movement which, I don't know when, must have taken a series of wrong turns
Such is always the case, as soon as anything becomes a "school of thought". From Christianity to patterns and agile, someone will evangelise a set of concepts that s/he strongly believes in, and they will be reinterpreted or exploited by others for their own purposes. For design patterns, it was the whole "Enterprise Java" sector who went overboard and became doctrinaire.
Steve Hanna introduced me to Christopher Alexander's work. I was consulting at Intel, writing the Intel 4004/4040 native code assembler for the Intellec Microcomputer Development System. Steve and I shared a fascination in how systems and program get designed. Steve got me to read Notes on the Synthesis of Form and I was hooked. Somehow I'd missed it when it appeared in the Whole Earth Catalog. It certainly influenced my thinking. Years later, I got to know Christopher Alexander, the creative mind, and was continually surprised at how similar architecture and computer systems design are to each other. Christopher came to Stanford and gave talks. He was inspiring and exciting.
In my opinion, Gabriel has a better and deeper understanding of Christopher Alexander's pattern language and how it can be applied to software than the whole Software Pattern movement which created a very different interpretation of patterns.
Christopher Alexander actually wrote the Foreward to this book and it's interesting because on the one hand he describes how Gabriel seems to understand his work better than his architect colleagues. But, not being a practioner, he wonders how his ideas will translate into software. It's an interesting read. And the book is too.
I have been citing "A city is not a tree"[1] whenever our product managers are getting too loud about how to make cities more livable by plugging IoT into all the things. The issues he calls out goes far beyond "SmartCities". It's everywhere in Tech.
I don't remember which volume it was from, but doing any general maintenance I always remember this suggestion of his:
Work on the most neglected area first -- e.g., work on the most neglected outdoor area of a property first.
I don't recall his specific reasoning, but in my mind the essence was: Otherwise you will be acting on displacement anxiety and When an eyesore is taken care of first, your perspective on potential other improvements will change.
> If we always build on that part of the land which is most healthy, we can be virtually certain that a great deal of the land will always be less than healthy. If we want the land to be healthy all over - all of it - then we must do the opposite. We must treat every new act of building as an opportunity to mend some rent in the existing cloth; each act of building gives us the chance to make one of the ugliest and least healthy parts of the environment more healthy - as for those parts which are already healthy and beautiful - they of course need no attention. And in fact, we must discipline ourselves most strictly to leave them alone,so that our energy actually goes to the places which need it. This is the principle of site repair.
This is the most efficient way (IMHO) to raise the average quality of an installation / system, not to strive for a 1% improvement in the top end (while expending 10x the effort in doing so for said 1%, rather than the inverse).
This is one of those rare delights; an approach which is as powerful as it is simple.
I treasure my copies of all of Alexander's books, but most especially A Pattern Language. It's beautifully printed and bound and it's a joy to come back to again and again. I'm not an architect or urban planner; it's just that the ideas are so compelling and beautiful.
Fascinating book, full of interesting ideas. I bought my copy in the 1980's. I had a roommate then who I reconnected with lately. He remembered the book and asked about it. I dropped in on him a couple weeks ago and left my copy on loan so he could spend some time with it.
It's a really good series, and the accompanying book is also recommended (I read the book first, not aware that it was a book-of-a-TV-series). Christopher Alexander is in Episode 1 from about 20'50". https://www.youtube.com/watch?v=maTkAcDbrEY
Every time I meet an architect or designer, I ask them about Alexander, and in the sample of about 12, only one (a world renowned architect) had heard of him. He's hugely influential in software, and was a big influence on me in the 90's and 00's, along with Tufte, Hofstadter, and Feynman.
I think it was hacker culture that really bouyed his ideas and kept them in the popular consciousness, and in turn, his ideas became really foundational to hacker culture as well. His passing is if not the loss of a pillar, it is at least a buttress.
I learned about his work through reading The Not So Big House. I've also asked Architects and Builders I've met if they are familiar with his work or the related Not So Big House movement, I haven't met a single one that have heard of either. It seems so strange to me. It would be like meeting a programmer who has never heard of functional programming. Even if you choose to use OOP instead of functional programming, surely you've at least heard of functional programming. How can you be an architect and be ignorant of Christopher Alexander??
Curiously, the Prince of Wales was a big supporter of Alexander's ideas, and wrote a book about related themes. He's on the talking circuit these days, and it might be interesting for someone to ask him his thoughts on Alexander.
His book on “Harmony” is highly recommended. I only knew him through tabloids. But based on his book, I have a ton of respect. Where is he on a talking circuit?
I think I misinterpreted an invitation to a munk debate as being a dialogue with him, when in fact it was about him. However, his book Harmony is sitting in my pile, as I am very interested in his views on conservation, architecture, cities, and the environment.
I had no idea Christopher Alexander was a software development luminary. I knew him via _A Pattern Language_, and I'm way more into architecture and physical space design than I am software. Now I'm mega interested to absorb his thoughts on software. I expect I'll be much better for it.
OOPSLA talks of that era were fantastic. Alan Kay has often paid tribute to Christopher Alexander in his talks and I cannot resist mentioning this from Alan from the following year https://www.youtube.com/watch?v=oKg1hTOQXoY
Too bad Kay has never paid enough tribute to Nygaard and Dahl in the same manner. His comments from that '97 OOPSLA talk on Simula being incomprehensible are absurdly misleading.
Simula67 was already known in academic circles by the early 70s. Donald Knuth had first taken an interest in Simula I after a visit in Oslo but couldn't manage to bring it to Stanford because of the very high licensing fees the Norwegian Computing Center were charging for it. That first iteration of the language was more focused on being a general purpose "system description" language for different kinds of real-life simulations (this would also kickstart Nygaards work on the social impact of technology and the beginnings of user-oriented system development, then participatory design). Simula67 however wasn't the "incomprehensible" language that Kay describes. The second iteration was much more focused and had all the elements of modern object-oriented patterns: classes, subclasses and inheritance, objects, object references and attributes, object dot notation, polymorphism, etc.
So Kay's take on Simula being this strange language he had to "make sense of" for his work on Smalltalk, or even the fact he claims he coined the term "object-oriented" is total BS. Here's a more nuanced and impartial account of Simula by James Gosling, if you want to know more: https://www.youtube.com/watch?v=ccRtIdlTqlU.
This is very interesting, but his main concerns (the creation of what he calls "living structures", "nurturing structures", and things that make people "feel whole") seem to be completely and utterly divorced from what people in the computer field are interested in.
These structures are akin to residual neural net motifs. "Fine-grained control at every level" is the name of the game. Pattern Languages are languages which obey the roughly same algebras as residual neural nets in context of transfer learning. Looks more closely at what Christopher Alexander says!!
Yes, I wonder what he felt about how some of the most well-compensated members of our society spend their efforts on building software that gets people to click on ads
What a sad day. Never met him personally. But from what I heard this man’s influence has reached from architecture all the way to Wikipedia and Tesla. Unthinkable how different our world today would be if it hadn’t been for his work. May he rest in peace. And may his ideas continue to live, and mingle, and add color to our world.
IMO Alexander's design pattern concept is intelligently superior to the terms trivialization in the atrociously highly rated GoF book. GoF enumerates the tedious patches one needs to use on cumbersome languages like Java or C++ due to the languages primitive nature. The main advantage of GoF that now when you say "Factory pattern" everyone knows sort of concept they are speaking of.
However.
In the scope of Alexander's work GoF patterns are of equal complexity, as if giving names to typical architectural items like "door" or "room".
Alexander's work is on a higher level - discussing how to perceive the complex totality the combination and co-existence of such design features create. GoF book names door a door. Alexander's book discusses how to design houses and communities. Completely different scale.
In software engineering terms I think the closest book that is the best analogue to The Timeless Way of Building in terms of discussing higher level patterns, and how to combine them, is perhaps the classical Structure and Interpretation of Computer programs that since it uses such an elegant language, it can skip the tedium and start with expressing of higher level patterns, and in the end how to combine them into a whole complex system.
You immediately see the difference when you open A Pattern Language and the very first pattern is:
> Wherever possible, work toward the evolution of independent regions in the worId; each with a population between 2 and 10 million; each with its own natural and geographic boundaries; each with its own economy; each one autonomous and self-governing; each with a seat in a world government, without the intervening power of larger states or countries.
No software pattern work has the audacity to start by suggesting that the ordering of the world's governance is relevant to the creation of good software.
> Indeed, since the book was published, a whole academic field has
grown up around the idea of "design methods"-and I have been hailed
as one of the leading exponents of these so-called design methods. I am
very sorry that this has happened, and want to state, publicly, that I
reject the whole idea of design methods as a subject of study, since I
think it is absurd to separate the study of designing from the practice of
design. In fact, people who study design methods without also practicing
design are almost always frustrated designers who have no sap in them,
who have lost, or never had, the urge to shape things. Such a person will
never be able to say anything sensible about "how" to shape things
either.
Poincare once said: "Sociologists discuss sociological methods; physi-
cists discuss physics." I love this statement. Study of method by itself is
always barren.
Most people know "A Pattern Language" because of the design patterns, but it's _this_ book that every software engineer (and everyone in the space of designing solutions) should read.
I agree it's a great place to start; it is much shorter, and contains stronger (or more obvious anyway) links with mathematics, graph theory.
We did a Christopher Alexander reading club some months ago and took some notes as a group using hypothes.is, it worked very nicely and anyone interested is welcome to join in:
That book is fantastic! It's absolutely thrilling design joyride through the most surprising of concepts - and yet it manages to send a very concrete message to designers of all disciplines who are required to build something novel that needs to meet real world requirements.
Minsky, vernacular architecture, graphs, old houses, how to design complex systems...
Notes on the Synthesis of Form provided intriguing insight into the theory and cultural impacts of design. As others have mentioned, he provided examples using architecture and biology. Quite fascinating albeit dry at times. Highly recommended. Thanks to the others for other reading suggestions.
While Christopher Alexander will be mainly remembered for A Pattern Language, I do think he was onto some really interesting philosophical ideas in his attempt to define life as an analog (as in, not binary) value of structure. He didn't have the words or precise knowledge to do it in The Nature Of Order series, but you can see him scratching at it.
Life is defined currently in a nebulous way that is primarily an internal property of an entity. When determining if an individual entity is alive we look inside it and dissect it into its components to determine whether they are organic.
I think what Alexander was trying to get at was that life is a presence of certain patterns. He identified these patterns through an architectural lens as 15 patterns. He is clear that there are less than 15, he just found it easier to teach these patterns to architectural students as 15 different patterns. These patterns are things like deep interlock between patterns (think of a complex carpet) strong borders and a diversity of scale in elements. Crucially these patterns are not an inherent property of some element, but rather a property that arises out of relationship with other elements.
I see a lot of truth in these ideas in that I think it makes far more sense to see life as an arrangement of matter into certain shapes that give rise to self-perpetuating and mutually reinforcing patterns. Christopher Alexander came at this idea from trying to articulate what exactly is so suffocating about modern architecture (and why it feels so anxiety inducing and alienating) but I think the implications are for Christopher Alexander characteristically broad.
I hope people like Nikos Salingaros continue going down this road.
I read about Alexander's Norwegian barns and their "quality without name" and how that perhaps should apply to software too. And surely it applies, but in practice is not practiced very much.
One reason this might be is that software applications are more complicated things than barns. And the kind of complexity that matters here is not really in the implementation but in the interface. To design great applications I believe you have to consider that user is just one part of the "system". It is not only software running on a computer, it is also software running in user's head and fingers and the protocols users can and will use to interact with the rest of the system.
When you design a software application you must decide how much and what will the system do and how much and what will the user do. That is a complicated decision and it is not easy to come up with the optimal choice. Possibilities are almost endless.
We don't usually consider the user as part of "software" but really they are, they are just parts in a bigger system with formal ways the user-part can and will interact with the computer-part of the system. Interaction with a barn is not trivial but quite simple compared to computer-based applications, I would think. But I agree the quality without a name is important to strive towards. It is, or would be, when everything seems to perfectly work together in different contexts and for different purposes.
I wonder how many software engineers, and how many of the GoF (Gang of Four) who wrote the software book that popularized patterns in the software world, actually read and thought about A Pattern Language. I'm sure some, but in my mind the subtitle "Towns, Buildings, Construction" examines patterns that are large in scope, medium in scope, and small in scope. One of my personal complaints about software patterns is that there are so few that are 'large scale'.
I think it's underappreciated how much Christopher Alexander influenced a generation of software engineers. Those building in the 1980s,1990s, and early 2000s were directly impacted by his work. I feel a lot of that culture has been lost over the last 15 years, which is a shame.
His core ideas have been riffed on so much since then that it won’t read as an original idea anymore, but it’s still a great read if you’re interested in thinking about how communities and building and people work.
> In 1965, Alexander wrote a much-cited essay, A City Is Not a Tree, one of the earliest and most trenchant critiques of the dendritic, sprawl pattern of city planning and development.
On the other hand, all dense old-world cities (London, Paris, Rome, even Tokyo, say) are... "dendritic". There's nothing wrong with that, and it has everything to do with the history of the ownership of all the bits of property on the city.
Sprawl is a problem, but sprawl is a new world problem that has to do with its very short history.
We've got about 500 years of old world folk moving to the new world, but the old world has thousands of years of history. Besides new world cities starting from much lower population density overall than the old world already had four to five centuries ago, there's also the fact that the last 100+ years of that history has had personal motor vehicles in it -- that's 1/4th to 1/5th of all the Americas' post-Columbus era, while it's more like less than 1/20th of the old world's history.
You can critique things like this all you like, but trying to do away with the "dendritism" that arises naturally is... unnatural, and requires a great deal of market distortion or use of force. Is that really something we want?
EDIT: Yeah, I probably read too much into that sentence!
Sprawl patterns are not caused by natural market forces.
They are caused and enabled by land-use zoning that uses state force to limit the use of private property, along with massive market distortions like government-funded freeways and the building of low-density infrastructure without a sustainable mechanism to pay for maintenance and operation of that infrastructure.
But I'm also not a free-market absolutist and I'm not sure I believe there has ever been an unencumbered free market. Markets are just a mechanism to organize and manage a complex system. There are always forces in place which nudge the overall behavior in one way or another while still leaving the market interactions to hash out the details. That's fine - we just need to nudge things is the "right" direction.
> On the other hand, all dense old-world cities (London, Paris, Rome, even Tokyo, say) are... "dendritic".
Not in the sense of the Alexander essay. It explicitly contrasts the interwoven connections of traditional cities with the artificial tree-like structure of modern planned cities.
"Tree", in the sense that Alexander uses it in that essay, is a math tree (e.g., a binary tree in CS), not an organic tree.
I highly recommend reading the essay for those who haven't seen it.
The sentence you quote does not give you enough information to make any kind of critique. It's OK to use the sentence as a writing prompt to write what toughs it brings into your mind, but that has little to do with the subject.
Alexander's critique is against rigid tree structure when a city should have connections between branches.
Don't forget that the market was heavily distorted in favor of sprawl.
Massive federal investments (subsidies) in:
* interstates and highways that made sprawl development possible.
* oil infrastructure and automobiles.
* suburban housing development designed to specifically exclude people of color, driving disinvestment from and leading to the collapse of cities.
None of these are natural new-world problems nor are they market driven, these are policy choices made. Pre vs Post WWII cities are structured and shaped completely differently as a result of these policies.
> We've got about 500 years of old world folk moving to the new world, but the old world has thousands of years of history. Besides new world cities starting from much lower population density overall than the old world already had four to five centuries ago
Humans have lived in "the new world" for at least 24,000 years. At the period when the first Spanish arrived in "the new world", it seems likely that there were cities here at least as large as anything in "the old world". By some calculations, "the new world" may have been home for between 10% and 33% of total human population worldwide.
What changed the development path in "the new world" was the arrival of "old worse" disease, which wiped out at least 80% of the human population here (perhaps 10% of humanity), and then a frankly genocidal process by European settlers built around ideas such as manifest destiny that intentionally completely ignored the millenia-old histories of human civilization here.
It is convenient to reset the clock in 1492 (or even 1776), but it is not honest.
A SWE in the audience spoke up, saying basically "look, we want to follow that approach, but it's hard, we have a lot of stakeholders to satisfy in order for a project to happen."
Alexander was unyielding. "Once you've worked with love, you won't want to work in any other way."
YMMW on the practicality of his advice, but it was super inspiring.