✉️ Not subscribed yet? Subscribe to the Newsletter
Future of Coding Weekly 2025/06 Week 3
2025-06-16 11:03
📝 Malleable software: Restoring user agency in a world of locked-down apps 🎥 Playing tag with dragons 🎥 AI's Non-Euclidean Geometry
Note: trying new process to generate the newsletter, let me know if something doesn't work :)
Share Your Work
🗨️ hamish todd: 🎥 AI's Non-Euclidean Geometry: when gradient descent's shortest path doesn't look like a straight line
Hey folks, AI-related video 😃 Sorry. The reason I'm thinking about the geometry of this is because I'm hoping it might lead to UI ideas, hence posting here.
🗨️ Mariano Guerra:
Playing with a time traveling WebAssembly visual interpreter, just added the call instruction and call stack
🗨️ Dan Peddle: sombra - Chrome Web Store
I’ve been somewhat frustrated by limitations in AI agents when it came to both them deciding which web resources might be relevant, and their inability to retrieve private data. If it’s not public, you have to have some method to expose that data to (for example) Claude Desktop or similar - and it has to live in a different silo. Rebuilding all that context time and again is also a pain.
With all that in mind, and with some downtime in hand, I’ve put together Sombra - a tool that combines traditional web scraping techniques (the original arc90 readability algorithm) with a modern, authenticated remote MCP connection, consumable by compatible clients.
Web pages that you save are stored as markdown and can be organised into collections - and those collections are then available via MCP resources. Scraping happens client-side, so if you can see the content in Chrome, you can save it to your collection. I added screenshot capture too - but haven’t exposed that to MCP yet. I’d be curious if that might be helpful to any of you - it feels like it might be too much when the markdown is available - maybe the visual references could be another resource? About the name, why sombra? I was thinking of sci-fi references such as Peter Hamilton’s u-shadow, or the idea of a “shadow” in Silo - I’d like to evolve this concept further in the future.
The stack is Clojure/Datomic on the backend with a TypeScript Chrome extension - the early release is now publicly available.
If any of this sounds interesting, I’d love some feedback! It’s one of those projects that scratches a personal itch, and then possibly got a bit out of hand - but having built it, it feels like it would be a shame not to put it out there, in case it helps others. Thanks!
🗨️ Mariano Guerra:
Wasm visual interpreter update:
- block, loop, break, break if, i32 comparison ops
- function inspector and switcher
🗨️ guitarvydas: 📝 Using Existing PLs as Assembly Languages
DevLog Together
🗨️ Tom Larkworthy:
So for the LLM to explore the dependancy graph I added the "dependsOn" cross-links to the already well worn "moduleMap" function. Now I have that information available I can visualize it nicely! and furthermore I made it reactive to the runtime changes so its always up to date.
🗨️ Oleksandr Kryvonos:
accidentally I discovered that typing without backspace might be somewhat fun
https://uprun.github.io/web-editor/keeped-2025-06-15-no-backspace-challenge.html
Thinking Together
🗨️ Joshua Horowitz:
Two related things:
- The LIVE Workshop deadline is July 21st, so there’s still plenty of time to get a submission together! Please let me know if you have any questions, or want to talk about a submission.
- I’ve been cooking up a LIVE Primer. It’s an overview of LIVE-adjacent research – mapping out some territory, sharing some advice, & curating some citations. It’s rough right now, but I think there’s good stuff in there already. Please take a look and let me know what you think. (Especially if there’s something you wish was in there that isn’t; that would be great to know.)
Thanks!
🗨️ Konrad Hinsen:
I think that Kartik Agaram’s recent devlog post (mentioned in this thread) deserves a thread of its own, outside of the discussion of live programming. The topic that interests me in particular is what he calls the vendor/owner divide, which bothers me as well.
More generally, it's a dependency chain from hardware vendor via OS vendor and programming tool vendor up to the owner, end user, or whatever else we'd call the person or team that wants to use computation as a tool for their own goals. Along this chain, everyone has the power to break the work of the people further down the chain, unless there is some counteracting force such as competition between multiple vendors of fungible products.
As somebody at the end of the chain, if I want to preserve my agency, I have basically two choices (plus hybrids): I can be selective in my dependency chain, only accepting dependencies whose vendors I consider friendly and ethically sound. Or I can restrict myself to dependencies that are fungible because they implement standards for which there are other implementations as well.
Out of the two, my preference is for the latter, which is clearly the more robust strategy. Vendors change over time, and even those that promise not to be evil today can drop this promise tomorrow. Vendors or their products can also disappear for lots of reasons. In fact, a vendor that is serious about being ethically sound should signal this attitude by implementing standards, reducing its own power over its clients. Except of course that there are no standards for most software interface layers, and you cannot create one unilaterally either. Nor quickly, because good standards require many design iterations involving multiple vendors and users. Evolving standards is expensive.
There's a third aspect to consider, which is code complexity. For simple enough software, a vendor provides the convenience of a ready-made and tested implementation, but if the vendor disappears or becomes evil, I can maintain the code myself, or convince someone else to do so. That's what early FLOSS advertised as its strength: you can always fork. Except that today's software stacks have grown too complex for this.
🗨️ guitarvydas: Solution Centric Programming
I created a document repo on github and a channel on discord programming simplicity for anyone interested in discussing and adding ideas...
from a substack article, brainstorming SCP
We explored how this principle led us from single-machine programming to *Solution Centric Programming* (SCP), which treats hundreds of small computing devices (Arduinos, sensors, actuators) as *new atomic operations* for automating specific problems, requiring *new recipe techniques* for combining them. Unlike traditional programming that forces all code through one paradigm, SCP enables *computational diversity* by letting each distributed node use the most appropriate programming paradigm (Forth for real-time control, Prolog for logic, FP for data processing, OOP for state management) as specialized atomic operations, while connecting them through pure data flow rather than restrictive function calls that impose control flow protocols. The key architectural insight is *Solution Centric Program Choreography* - a hierarchical tree structure where parent nodes contain the recipe logic for coordinating child atomic operations, eliminating peer-to-peer coupling that destroys scalability. This creates a new abstraction layer where solutions are choreographed through structured data flow between specialized atomic operations, each autonomous in their execution but coordinated through hierarchical recipes rather than lateral negotiation - representing the next evolutionary step in programming's fundamental cycle of creating atoms and recipes.
📝 Join the programming simplicity Discord Server!
Check out the programming simplicity community on Discord - hang out with 25 other members and enjoy free voice and text chat.
📝 Solution Centric Programming
Linking Together
🗨️ Mariano Guerra:
quartz: visual programming and dsp playground
🗨️ Ivan Reese: 📝 Malleable software: Restoring user agency in a world of locked-down apps
New Ink & Switch essay: Malleable Software: Restoring user agency in a world of locked-down apps
By Geoffrey Litt, Joshua Horowitz, and Peter van Hardenberg, with photos by Todd Matthews.
Little spoiler — this essay was written in our malleable environment Patchwork, and Geoffrey created some custom tools to help him write and edit the essay, detailing the experience in the essay. Meta :)
📝 Malleable software: Restoring user agency in a world of locked-down apps
The original promise of personal computing was a new kind of clay. Instead, we got appliances: built far away, sealed, unchangeable. In this essay, we envision malleable software: tools that users can reshape with minimal friction to suit their unique needs.
🗨️ Kartik Agaram: 🎥 The Web That Never Was
An alternate history of the tech industry
I can't believe I haven't seen this 6-year old talk before.
AI
🗨️ Tom Larkworthy:
building an agent turned out to be surprisingly simple.
I went through the Cline source code and wow, these agents are ultra simple! Force the AI to always call a tool. Have some special tools that delegate to the user for the interaction with the control loop. This is *it*.
Present Company
🗨️ Tom Larkworthy: 📝 Terminology: What is a "glitch" in Functional Reactive Programming / RX?
I was at programming 2025 and heard a developer struggling with glitching in reactive systems. Made me dig deeper into Observable reactivity model. I sometimes see glitching but its when I manually short circuit the dataflow graph. The actual engine is glitch free even when you put async tasks in the middle. I've properly tested it now!
📝 Terminology: What is a "glitch" in Functional Reactive Programming / RX?
What is the definition of a "glitch" in the context of Functional Reactive Programming?
I know that in some FRP frameworks "glitches" can occur while in others not. For example RX is not glitch free
🗨️ TodePond: 🎥 Live: Live
hello i am going to do a livestream later where i watch back through every todepond tech talk ive ever given to reflect on each one. i invite you to join!
It's another todepond livestream, at 5pm London time.
👨🏽💻 By 🐘 @marianoguerra@hachyderm.io 🐦 @warianoguerra
💬 Not a member yet? Check the Future of Coding Community
✉️ Not subscribed yet? Subscribe to the Newsletter / Archive / RSS
🎙️ Prefer podcasts? check the Future of Coding Podcast