Bit of a poetic turn of phrase, I suppose. Term borrowed from meteorology , meaning phenomena of intermediate scale. I guess I like connotations of a complex system that weather provides

Ah yes, OK. Thanks for clarifying. I'd love to talk more about system effects of using Clojure. I added it to my topic ideas. I do believe using Clojure (and pure FP in general) encourages systems to become more centered around data, and if so, it has beneficial knock-on effects for the whole system. Of course nothing stops you from creating a boatload of microservices in Clojure that act like glorified RPC endpoints in a network-level call-graph that makes chaos models look ordered, but hopefully the abandonment of OO leads to abandoning OO principles on the system level too. (I know we don't always get to control the surrounding systems.) Malcom Sparks, CTO of Juxt, has a good exploration of taking data-centric and functional thinking and applying it to the system level. https://www.juxt.pro/blog/atomic-architecture/

@john.t.richardson.dev It's good to hear from you again! Yeah, we haven't talked a lot about system-level design. We've focused primarily on topics within applications and services as opposed to between them. It would be fun to explore that. It sounds like your general process matches mine: determine the major information/computation needs of the system, rough out the relationships between them, and then figure out the particulars of each of those specific parts. As for data-oriented programming, https://clojuredesign.club/episode/042-what-does-it-mean-to-be-data-oriented/ is a good one. We're also going to address in an upcoming episode. Stay tuned!

@john.t.richardson.dev What you say about not relying on frameworks for structure is so true! I too have have learned to avoid layering my application on top of frameworks. Instead, I use frameworks and libraries for very specific problem domains. As you mention, React is a framework, but I think its lasting power is due to staying in it's lane: rendering markup from data. Frameworks that try to orchestrate your UI components and data flow and server communication (I'm looking at you, Angular), feel super risky to me. The alternative to using frameworks for structure is to push them to the edges. I think of them as "integrations" with their purpose. Eg. React is an "integration" with browser markup. Ring is an "integration" with HTTP. The core of your application should be centered around clear, pure, information domain models, and those drive the code at the edges. Just writing this has brought up a lot of thoughts. We'll have to do some episodes on this topic.