I love that book. I have read it vaguely in the light of future of code.

I think it's unclear whether he's right about us being able to tap into something within us to design our own buildings. It's an unfalsifiable claim because whenever someone can't design well, you can say they aren't tapping into it.

However, I do feel a lovely feeling swimming around when I read the book. I turn to it when I need to get out of the engineer's mindset and into a more holistic/intuitive sense of the world. I think we all have that sense, but it doesn't always express itself as architecture.

I would love to see someone like Alexander in our community, someone who can defy convention and build beautiful things by seeking the life and humanity in the thing.

And don't get me started about the patterns movement. Alexander says it was a failed experiment even in architecture, let alone in software engineering.

I actually haven’t gotten around to read the timeless way of building. But for anyone who like me has a bad association with patterns, I highly recommend Richard Gabriel’s exposition of them in the beginning sections of this book. He give Christopher Alexander and the idea of patterns life that I never felt in the Java community. dreamsongs.com/Files/PatternsOfSoftware.pdf

If you haven't read it, you might enjoy his forward to Patterns of Software.

Also, this talk he gave at OOPSLA in 1996:

YouTube

Transcript

Transcript of OOPSLA talk: patternlanguage.com/archive/ieee.html

Dorian Taylor has written quite a lot about how Alexander’s ~later~ work applies to code in his series The Nature of Software. This was a follow-up to his earlier piece about him which also mentions that OOPSLA talk:

The thing people who just look at patterns miss, is that Alexander himself renounced them. He said so plainly in 1996, at a keynote address to a room full of software developers; you can watch it yourself.

It’s helpful to realize that Alexander went through three distinct periods in his life:

• ~Notes on the Synthesis of Form~ and ~A City is Not a Tree~ we’re starting out extremely mathematically, although he quickly picked up that something didn’t quite work.
• ~A Timeless Way of Building~ and ~A Pattern Language~ explore the other extreme and look for practical ways to bring about the quality without a name through process and focus on the human side of building.
• But even the patterns didn’t ultimately help people create what Alexander had in mind and so he tries to synthesize both extremes in his magnum opus ~The Nature of Order~ .

Alexander went through these three distinct periods in which he changed his thinking considerably. Unfortunately, his most well-known books are from the earlier periods. Many ideas in them Alexander himself has deemed obsolete, and he has improved on them in more recent but less familiar works, like ~The Nature of Order~ .

If you want to read a little more about these periods, I recommend this article: patterns.architexturez.net/doc/az-cf-218793

And as this turns into a “best of” I’d also add Ryan Singer’s primer: vimeo.com/491222729

My summary notes (Kinopio) for reading on a rainy day kinopio.club/fzRyaURd_-AoBBi2ZwEK8

I would also recommend reading The Battle for the Life and Beauty of the Earth: A Struggle Between Two World-Systems. It discusses one of his firm’s bigger projects and the roadblocks that they ran into and I think there are many parallels to software projects in there.

I would, further, modify this to

• Fail.
• Fail again.
• Succeed.
• Productize.

Using type-checked, bloatware languages ain’t the way to perform steps 1-3.

Architecture ≡ 1-3

Engineering ≡ 3

Coding ≡ 4

Production Engineering ≡ 4

Q/A ≡ 4

...

Type checking allows you to detect failure even before you run the code. It's a way to fail even faster.

Just don't conflate "type checked" and "bloatware". It's definitely bad to have both, but they're not the same.

I really wish OCaml would take off. I really really wish 1ML would take off, but last I heard that's still a research prototype, so... :( I guess we're relying on Rust and Swift to carry the torch of nice types into the mainstream. (I like Rust, but everyone would be better served by it being a niche language for when GC is unaffordable.)

Ocaml is used by jane st. Idk if that's taking off necessarily, but by dollar effect it might rank fairly high in languages.

Typescript types aren't too bad. There's definitely some bloat though.

I would suggest: starting by critiquing the current technology.

For starters: I don’t know anything about BPMN, but, looking at the posted diagram, I see:

1. A wall of detail

• “simplicity is the lack of nuance”
• there seem to be no layers, everything is laid out flat
• breaking of The Rule of 7 (no more than 7+-2 items in an eye-full)

• the diagram is “too busy”

• Too many icons

• I count something like 5 different kinds of figures
• The rectangles have many kinds of sub-icons in the upper left corners
• At least 3 kinds of lines
• text too small to read

• EEs used to draw all sorts of icons on schematics, then, later, learned to draw only rectangles and lines and text

• Apparent breaking of Containment

• Arrows appear to poke through walls instead of being attached to well-defined Ports (aka “ad hoc”)

The system probably needs all of that detail, but, the reader should not be forced to read all of the details at once. If interested, the reader should be able to drill down into components to see more detail, then, drill down into that detail to see even more detail, ad infinitum.

[aside: Lispers hate XML because it is the only syntax uglier than Lisp]

I'm trying to figure out how to formally treat jobs that pass from humans to automation and back as continuations. An agent receives a continuation plus some description of work to do, does their part, adds it to the continuation's context or somesuch, and reactivates it, which may or may not be the same as assigning it to a human or kicking off a process. There's a certain sense where e.g. work tickets just trivially are continuations, but getting mileage out of the concept is tricky. Maybe someone here will make headway with it.

There do exist some nice DSLs for these. Essentially, workflows are Turing-complete programs, for multiple processors - some of which are humans while others are machines.

This one is called Flor: github.com/floraison/flor

Workflows require extreme decoupling (which I have come to call 0D). Synchronous software programming languages inhibit this kind of thing.

(FMI: where is this jpg? I want to pass it on to a friend, but I haven’t found it in the github yet).

Flor: github.com/floraison/flor

Screenshot is from this page: jmettraux.skepti.ch/20190407.html

There do exist some nice DSLs for these. Essentially, workflows are Turing-complete programs, for multiple processors - some of which are humans while others are machines.

This one is called Flor: github.com/floraison/flor

big shout out to the paper for using the term “Algolic” to refer to languages related to ALGOL.

I think I’m specifically interested in trying to draw out connections between Elephant 2000 and theory making.

Never heard of it before, or wasn't ready to take it seriously. It looks neat. I don't suppose there's a prototype interpreter out there?

And yes, "Algolic" is fun. :D

I’m not aware of any implementations of Elephant 2000, but re-reading it last night I was struck by some similarities between Elephant 2000 and INFORM.

Huge fan of Elephant 2000. It shows just how far we still have in expanding the linguistic side of programming. I don't think anyone has implemented it, but I think you can see the influence in Dynamicland's RealTalk. Its keywords Wish and Claim are both speech acts. The fact that dynamic land has effects in the actual world through its words makes this fact seem to be far from a coincidence. Sadly, Elephant 2000 isn't in Bret's list of papers, so I can't be certain he has read it, but I'd be surprised to find out this is an accident.

Definitely recommend reading Searle or Austin on speech acts. Searle is definitely less jargon heavy and incredibly readable.

Potentially because I’m especially and acutely APL-pilled at the moment, I was struck by sort of sneaky connections between speech acts and APL’s. While the glyphs aren’t really “readable” as text, they are readable, e.g. “union without intersection” does just that

I mean, my particular FoC interests are quite visual in nature, and so I'm just picking up WebGPU now that it's about to ship in Chrome. So for a certain perhaps stretched definition of "FoC adjacent", I'll be reading webgpufundamentals.org (by Gregg Tavares) and perhaps some stuff about ray tracing.

You?

I’ve been going down an APL rabbit hole, lately…so, maybe that.

Ah yes, Apple. Good programming language, that.

(Sorry — reference to next month's episode. Just hide it under your hat.)

@Eli Mellen I’d like to learn more about your APL weekend — what are you reading? Did you find a good resource that talks about an APL ~implementation~ (apart from the original Iverson papers)?

Stefan Lesser I haven’t read anything about implementations, but I have looked at the few open source ones I’ve run across and found those pretty interesting.

• Kona
• oK
• lil (embedded in the larger decker project)
• bqn

I’ve also found the J wiki and the kdb+ and q websites really helpful.

Also interesting in my opinion: APRIL, an APL dialect embedded in Common Lisp (github.com/phantomics/april). I see APL more as a DSL, so it makes sense to embed it into a wider ecosystem.

I can see why it comes across as a DSL, but I’m mostly interested in it for its fundamental design around arrays as the primary data structure. Kind of like Lisp with lists. Commercial implementations ride on that wave because it gives them interesting ways to optimize for parallel execution. But I think it’s an interesting design decision to basically treat everything as a collection and kind of look at a single scalar as an “exception” and design a language around that.

Arrays as a primary data structure are interesting indeed, but the problem of the APL family has always been that arrays are its only data structure (in contrast to Lisp, that has other data structures besides lists). Nested/boxed arrays were a big step forward, but they remain limited and, together with the weak abstraction facilities, make APL a pain to use for many tasks. Add to this that typical implementations don't care about interfacing to the rest of the world, and you easily trap yourself in an island that is fascinating but limited.

However, as you say, the notion of plain values being a special case ("rank 0") of a uniform collection type is interesting and pratically relevant. It's what makes it difficult to implement APL ideas in other languages. This has been the main struggle in the early days of Numerical Python, when we tried to make Python scalars work as rank-0 arrays (and mostly failed). Later NumPy versions introduced its own scalar types for that reason, which have then been an eternal source of confusion for many users ("why is an element of a float array not a float?").

k has dictionaries, and derivatives like Kerf even added tables as first class constructs. Also Russ Cox solving the advent of code using ivy is pretty interesting… youtube.com/watch?v=ek1yjc9sSag

Aaron Hsu’s thesis is interesting reading as well..

scholarworks.iu.edu/dspace/handle/2022/24749

Thanks! I haven't played with K yet, nor any of its derivatives. And Ivy looks interesting as well as a pragmatic tool that makes APL more accessible in a command-line environment.