I real liked the orgmode workflow b/c the code was self documenting in a sense. I had a very similar workflow for many years (though I've since stopped) But I do remember that in the leiningen days when I was first learning Clojure, the idea of tangling and attaching my own fork was just too intimidating and confusing. With the deps.edn workflow it'd have been less of a hassle now

Thank you for all your work. I still used geom basically every week (generating graphics for my PhD)

Your blog post is great. I think your point about the silo'ing and lack of cross pollination of idea between langs/frameworks is interesting, but also a product of just time-investment. I used to code C++ and the C++ gurus were always very miopic b/c they simply had no time for anything else.

To the last idea, I feel the ease of creating and having performance available is always in tension. I have a friend who works in Touchdesigner and I'm always left a bit embarrassed that no written programming language seems to hit the same level of productivity. Going down the stack can be fruitful, but I think there are still more levels of abstraction that need to be explored. At a high level.. even if you're writing immutable functional code.. it just all still feels too coupled to me. These days, I'm personally think the next step is something like Pathom. Where your declare decoupled relationships between inputs and outputs and have a engine derive your computation.

Note that part of the problem was that the library was written in a highly unusual literate style. So you had to clone the repo, then use Emac's Orgmode to tangle it to get the Clojure source code. This created a lot of friction for people to contribute.

Also before deps.edn (Clojure built-in dependency management) was added to the language you had to use leiningen which didn't make using a locally cloned fork as easy as it is now (now you just point to the library file directory and it "just works")

All the pieces are very decoupled and in pure Clojure (unlike a lot of the heavier scicloj stuff that's being use nowadays)

https://en.wikipedia.org/wiki/Flexi_disc

I remember to listening to some in my childhood and never understood why the tech was not the standard (relative to the brittle cumbersome vinyls). Maybe the sound quality is worse. Unsure

The Clojure docs should be more straightforward about the interfaces that are available and targetted

You can still have a problem of not knowing which is required of an argument, but its usuallt clear contextually

Though im not if its production-ready and "done" or just adandoned

"Clojure heavily favors a style of coding which creates impedance mismatch when dealing with other systems" "I'm excited to bring what I've learned from Clojure to new languages and new kinds of problems"

It feels like these two things are going to be in tension :) In my little experience using any other languages post-Clojure, it now feels like a huge step back. Every library is stateful and fighting against you.

An interesting system to explore in the realm of "soup of keys" is Pathom and the GraphQL associate systems (though given the writer's experience I'm guessing he/she is familiar with them)

The criticisms of kondo I think is interesting and .. on reflection - yeah the design is kinda disappointing

Do you have any thoughts of Project Leyden? It sounds like it'll solve the startup speed problem and make these projects redundant, but maybe I'm missing some element

Thats been my understanding of the crux of mystery.

Would love to be corrected by someone more knowledgable though

Do you have any idea/guess why Injest hasn't been folded in to core? It seems a natural extension, so I worry if it has some hidden footgun

It's important to highlight that the it doesn't enforce any single model of how to hook up your GUI and state management. The built-in subscription model is fantastic, but you can do whatever suits you.

A big change was added in v1.9.0 that's not really documented in the README

https://github.com/cljfx/cljfx/blob/master/CHANGELOG.md#190-...

With the new extension lifecycles you can pretty much design and hook up any GUI system you'd like. You can even have different GUI sub-trees have separate systems entirely.

For instance I hooked up CLJFX with declarative Pathom state management using these new lifecycles: Small demo: https://github.com/kxygk/ednless/blob/master/pathomfx.clj

I'm curious what you found inadequate with the existing solutions?

I remember when I started writing Clojure I'd use stuff like Records to encode the data-shape. Paired with Protocols they're quite powerful when the interface is more important than the shape. But in most situations the flexible data shapes are what make programs very easy to extend/evolve.

Though to my mind the correct solution would be to launch a program + VM, then freeze/store the program state. Then you could just memcopy+execve the program and immediately skip all the initialization

(after a bit of Googling it seems this isn't a new idea haha, and it's in the JVM roadmap with Project Leyden. Should come out in maybe JDK 27 and make a lot of this stuff obsolete)

https://www.nesdis.noaa.gov/news/noaas-space-weather-mission...