You are viewing archived messages.
Go here to search the history.

Josh Justice 2023-04-10 12:44:38

Has anyone read Christopher Alexander’s The Timeless Way of Building in light of future of code? He’s the literal architect whose concept of patterns inspired the software patterns movement. In practice, Java enterprise software patterns are a lot of the past-of-code that we want to get away from. I’ve read that Alexander thought that community missed the point, and from Timeless Way I believe it. From the first chapter he gets into the concept that people should be able to build their own buildings, that it doesn’t take extensive planning, and that it resonates with something very natural within us and within the world. I don’t want to say more as I really think you need to read it in context for it to sink in; but I’d recommend picking up a copy.

Eric Normand 2023-04-10 14:19:56

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.

Jimmy Miller 2023-04-10 15:00:18

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.

Benji York 2023-04-10 15:27:54

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

Eric Normand 2023-04-10 15:52:15

Also, this talk he gave at OOPSLA in 1996:



Joshua Horowitz 2023-04-10 18:38:18

Transcript of OOPSLA talk:

Karlin 2023-04-10 21:52:49

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.

Stefan Lesser 2023-04-10 22:58:53

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:

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

Paul Tarvydas 2023-04-11 08:55:45

My summary notes (Kinopio) for reading on a rainy day

Vijay Shankar Venkataraman 2023-04-11 14:37:45

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.

Paul Tarvydas 2023-04-11 08:58:24

Brooks said in the Mythical Man Month.


Fail again.


You want to find a way to fail-fast the first two times. Using type-checked, bloatware languages ain’t the way to fail-fast.

Paul Tarvydas 2023-04-11 08:59:00

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


Joakim Ahnfelt-Rønne 2023-04-11 16:01:55

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

Andrew F 2023-04-11 17:04:13

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.)

Ulysses Popple 2023-04-16 10:52:25

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

Ulysses Popple 2023-04-16 10:53:24

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

Nilesh Trivedi 2023-04-11 13:32:14

I've been thinking: We might need new languages for describing workflows that involve both humans and bots. Something much nicer than BPMN (which is XML-based):

Paul Tarvydas 2023-04-11 14:08:13

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]

Andrew F 2023-04-11 17:10:06

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.

Nilesh Trivedi 2023-04-13 08:27:40

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:

Paul Tarvydas 2023-04-13 10:42:06

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

Paul Tarvydas 2023-04-13 10:47:11

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

Nilesh Trivedi 2023-04-13 13:00:55
Nilesh Trivedi 2023-04-13 08:27:40

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:

Eli Mellen 2023-04-12 22:50:15

I’ll be leaning a discussion at my work about Elephant 2000 soon, and found this very valuable context to help ground the paper in some common, yet not clearly defined terms.

Anyone have thoughts on Elephant 2000?

Eli Mellen 2023-04-12 23:17:27

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

Eli Mellen 2023-04-12 23:27:06

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

Andrew F 2023-04-13 02:29:58

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

Eli Mellen 2023-04-13 10:50:09

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.

📝 Inform 7

Jimmy Miller 2023-04-13 14:29:31

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.

Eli Mellen 2023-04-13 14:34:29

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

Eli Mellen 2023-04-14 20:17:12

Anyone planning to read anything interesting and future of code adjacent this weekend?

Ivan Reese 2023-04-14 23:22:47

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 (by Gregg Tavares) and perhaps some stuff about ray tracing.


Eli Mellen 2023-04-15 00:20:23

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

Ivan Reese 2023-04-15 00:46:47

Ah yes, Apple. Good programming language, that.

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

Stefan Lesser 2023-04-15 08:58:06

@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)?

Eli Mellen 2023-04-15 11:23:40

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.

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

Konrad Hinsen 2023-04-15 13:36:09

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

Stefan Lesser 2023-04-15 13:57:51

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.

Konrad Hinsen 2023-04-15 14:24:33

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?").

Vijay Chakravarthy 2023-04-15 15:26:19

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…

Vijay Chakravarthy 2023-04-15 15:27:34

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

Konrad Hinsen 2023-04-16 07:33:21

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.