Solution Centric Programming
2025-06-12
TL;DR
I brainstormed with Claude 4.0 this morning over coffee, then asked it to summarize the discussion. A copy/paste of the whole conversation is included in the appendix.
Programming is the act of creating atomic operations for abstracting automatable solutions to problems and techniques for creating recipes of such atomic operations.
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.
I’m sure that I missed mentioning many paradigms, techniques and ideas, like Statecharts, FBP. I consider this to be a “living document” that should evolve over time.
What have we got?
What don’t we have?
See Also
Email: ptcomputingsimplicity@gmail.com
References: https://guitarvydas.github.io/2024/01/06/References.html
Blog: guitarvydas.github.io
Videos: https://www.youtube.com/@programmingsimplicity2980
Discord: https://discord.gg/65YZUh6Jpq
Leanpub: [WIP] https://leanpub.com/u/paul-tarvydas
Gumroad: tarvydas.gumroad.com
Twitter: @paul_tarvydas
Substack: paultarvydas.substack.com
This one reminds me of an economics problem, almost like the economics of firm size, although there's surely a better analogy. But let me see if I can explain. Like if you build part of your app in Prolog and part of your app in OOP, there is some overhead associated with that. You have to maintain different environments, dependencies, processes, documentation, etc. But there is some point at which that overhead is worth it. We've seemingly decided (or have we merely been sold the idea... :/ ) that the decoupling is worth it for web apps (React + API).