The past few days I've been thinking a lot again about one of the thought/design models most influential on my own #OpenSource practice: Frank Duffy's architectural pace layers (and Stewart Brand's subsequent extension to different contexts), their different timescales and interactions as basis for resilient system design:

1. Each layer exists & operates independently, moves at different timescales (from seconds to millennia and beyond)
2. Each layer influences and only interacts with its direct neighbors

"Fast layers innovate, slow ones stabilize." — S.Brand

I always found that model super helpful for analyzing and deciding how to deal with individual projects and components in terms of focus/effort, and asking myself which layer this thing might/should be part of. Lately though, I keep on trying to figure out how to better utilize that model to orient my own future practice, also with respect to the loose theme of #PermaComputing and how to frame and better organize my own approaches to it, incl. how to reanimate or repurpose some of the related, discontinued, but not invalid research & projects I've been doing along these lines over the past 15 years...

I understand and appreciate most of the focus on #FrugalComputing & #RetroComputing-derived simplicity as starting points and grounding concepts for attempting to build a more sustainable, personal, comprehensible and maintainable tech, but these too can quickly become overly dogmatic and maybe too constraining to ever become "truly" permanent (at least on the horizon of a few decades). I think the biggest hurdles to overcome are social rather than technological (e.g. a need for post-consumerist, post-spectacular behaviors), so I'm even more interested in Illich/Papert/Nelson/Felsenstein-inspired #ConvivialComputing, #SocialComputing, IO/comms/p2p, #Accessibility, UI, protocol and other resiliency design aspects becoming a core part of that research and think the idea of pace layering can be a very powerful tool to take into consideration here too, at the very least for guiding (and questioning) how to approach and structure any perma-computing related research itself...

Given the current physical and political climate shifts, is it better to continue working "upwards" (aka #BottomUpDesign), i.e. primarily focusing on first defining slow moving, low-level layers as new/alternative foundations (an example here would be the flurry of VM projects, incl. my own)? Or, is it more fruitful and does the situation instead call for a more urgent focus on fast-moving pace layer experiments and continuously accumulating learnings as fallout/sediment to allow the formation of increasingly more stable, but also more holistically informed, slower moving structural layers to build upon further?

It's a bit of chicken vs. egg! In my mind, right now the best approach seems to be a two-pronged one, alternating from both sides, each time informing upcoming work/experiments on the opposite end (fast/slow) and each time involving an as diverse as possible set of non-techbro minds from various fields... 🤔

Its such a joy to watch! Don't know if it has more to do with moving to Mastodon and following a quite different crowd of people, but even before that, for the past few years I started sensing a (re)growing interest in #Forth-style languages and related philosophies, i.e. low fat, low energy, minimalism, self-sufficiency, interactive programming, dynamic systems, DSLs, VMs, emulation etc. Renewed interest in all this also seems to come from people with vastly different backgrounds & ages. Forth being one of the most underappreciated langs ever, 10 years ago it felt (subjective experience, no proof!) most active Forthers were either a) #RetroComputing people who've been using the language for decades and/or b) people working w/ severely resource constrained embedded devices (often an overlap). These groups still exist ofc, but I wouldn't be very surprised to learn if demographics taking an active interest (above and beyond doing some toy examples) have started shifting noticeably.

Back in 2015, the ForthHub org on GitHub had a dozen or so members, today its ~240. /r/Forth also has 3k members now, which isn't too shabby (even though a mere blip in the greater picture, but still...)

Is some of this due to more people getting fed up with heaviness of existing mainstream langs & tooling, looking for lighter alternatives? I don't know. Maybe more people are finding their way to functional programming (incl. getting pre-exposed to REPLs and their life-changing impact/discovery of interactive dev processes) and from there taking the smaller step to explore concatenative/stack-based langs...? 🤷‍♂️

Enough hypothesizing — it's just all _very_ exciting to watch how this is developing and hopefully new ideas & learnings from other langs/envs finding their way into Forth-lands!

“…Forth does it differently. There is no syntax, no redundancy, no typing. There are no errors that can be detected. …there are no parentheses. No indentation. No hooks, no compatibility. …No files. No operating system.” — Chuck Moore

Ps. Now go check out @ratfactor's great talk/summary/history on the matter:
https://mastodon.art/@ratfactor/109925520445016458

Ps2. Shameless plug, if you want to try out a Forth in the browser, check out my VM/REPL (incl. screen casts, Forth shaders/webaudio examples):
https://thi.ng/charlie

ratfactor

2023-02-25 13:05:29

I would apologize for posting what at first appears to be another "tech toot"...but since I churned out almost 40 drawings for this talk on the Forth programming language, I don't feel bad about it at all. Here's the slides:

http://ratfactor.com/forth/forth_talk_2023.html

I happen to know some of you enjoy space ships, calculators, and old computers as much as I do.

#MastoArt #RetroComputing #Forth #ConfusedCat

Dave's Forth Talk 2023

^{ratfactor.com}