Series A · djuleayo

Series A · djuleayo https://316c0611.personalpage-ahl.pages.dev/series/series-a/ Hugo en Dynamically Generated Languages vs MCP Servers https://316c0611.personalpage-ahl.pages.dev/posts/dynamical-languages/ https://316c0611.personalpage-ahl.pages.dev/posts/dynamical-languages/ Sun, 18 Jan 2026 17:10:43 +0200 <h1 id="dynamically-generated-languages-solve-the-same-class-of-problems-as-mcp-servers--and-do-it-better"> Dynamically Generated Languages Solve the Same Class of Problems as MCP Servers — and Do It Better <a class="heading-link" href="#dynamically-generated-languages-solve-the-same-class-of-problems-as-mcp-servers--and-do-it-better"> Link to heading </a> </h1> After battle-testing these ideas in practice, here is my conclusion: Centralized interaction and intent architectures are inevitable. The only real question is whether we build them as formal systems or probabilistic agents. <hr> <h2 id="from-clicking-and-scrolling-to-invoking-capabilities"> From Clicking and Scrolling to Invoking Capabilities <a class="heading-link" href="#from-clicking-and-scrolling-to-invoking-capabilities"> Link to heading </a> </h2> User interaction is moving away from clicking and scrolling and toward invoking capabilities directly, most notably via voice. This shift is powerful: <ul> <li>If you can name a capability, you can invoke it</li> <li>Interaction becomes direct</li> <li>UX complexity drops dramatically</li> </ul> From a UX-complexity standpoint, this is a clear win. However, this change forces a fundamental architectural shift compared to traditional frontend setups. <hr> <h2 id="react-and-the-problem-of-distributed-capabilities"> React and the Problem of Distributed Capabilities <a class="heading-link" href="#react-and-the-problem-of-distributed-capabilities"> Link to heading </a> </h2> Consider a typical React application. In React: <ul> <li>Capabilities are exposed through components</li> <li>Components expose behavior via props and callbacks</li> <li>Capabilities are therefore distributed by construction</li> </ul> There is no centralized place where “what the system can do” exists. Trying to centralize this in React quickly reveals deep friction: <ul> <li>Hooks produce unstable references across renders</li> <li>Central registries must constantly re-register handlers</li> <li>Context-based solutions become brittle and stateful</li> <li>Unsubscribing DOM listeners requires the exact same function reference</li> <li>That reference is often no longer available or stable</li> </ul> Yes, you can build a capability registry on top of React. But it is: <ul> <li>Clunky</li> <li>Hard to reason about</li> <li>Tightly coupled to rendering lifecycle</li> <li>Architecturally inverted</li> </ul> All of this is a strong signal: centralized capability invocation does not belong inside the UI layer. <hr> <h2 id="centralization-is-not-optional"> Centralization Is Not Optional <a class="heading-link" href="#centralization-is-not-optional"> Link to heading </a> </h2> Now compare this with a system like the Visual Studio Code command palette. VS Code exposes: <ul> <li>A centralized</li> <li>Runtime-configurable</li> <li>Discoverable</li> <li>Uniform command surface</li> </ul> Once a command is registered: <ul> <li>It does not matter where it lives</li> <li>It does not matter which UI triggered it</li> <li>It can be invoked uniformly</li> </ul> This is not an accident. It is a capability-first architecture. <hr> <h2 id="the-natural-conclusion-a-decoupled-capability-layer"> The Natural Conclusion: A Decoupled Capability Layer <a class="heading-link" href="#the-natural-conclusion-a-decoupled-capability-layer"> Link to heading </a> </h2> What naturally follows is a module that: <ul> <li>Is decoupled from the frontend</li> <li>Has no dependency on UI frameworks</li> <li>Accepts voice or textual input</li> <li>Emits discrete, authorized commands</li> </ul> At first glance, this smells like parsing. And that is exactly what it is — with one important caveat. <hr> <h2 id="this-is-parsing--not-ai"> This Is Parsing — Not AI <a class="heading-link" href="#this-is-parsing--not-ai"> Link to heading </a> </h2> Traditional parsing assumes: <ul> <li>Full input available upfront</li> <li>A lexing phase</li> <li>A parsing phase</li> <li>A final AST</li> </ul> User interaction does not work this way. For voice and interactive input we need: <ul> <li>Incremental parsing</li> <li>Partial feedback</li> <li>Real-time guidance</li> <li>Asynchronous evaluation</li> </ul> This is not AI. This is asynchronous parsing. That distinction matters. <hr> <h2 id="mcp-servers-and-the-core-problem"> MCP Servers and the Core Problem <a class="heading-link" href="#mcp-servers-and-the-core-problem"> Link to heading </a> </h2> MCP servers attempt to solve a similar problem: <ul> <li>Centralized capability invocation</li> <li>Access via natural language</li> <li>Location-agnostic execution</li> </ul> In practice: <ul> <li>Once a capability is integrated, its origin no longer matters</li> <li>If you can name it, you can invoke it</li> </ul> On the surface, this sounds ideal. It is not. <hr> <h2 id="why-informal-invocation-is-dangerous"> Why Informal Invocation Is Dangerous <a class="heading-link" href="#why-informal-invocation-is-dangerous"> Link to heading </a> </h2> MCP-style systems rely on: <ul> <li>NLP → mapping informal language to formal side effects</li> <li>Agents → which can and do hallucinate</li> </ul> This creates a fundamental mismatch: <ul> <li>Informal input</li> <li>Formal consequences</li> </ul> The moment real side effects exist, you must introduce: <ul> <li>Authorization</li> <li>Capability scoping</li> <li>Denial rules</li> <li>Auditability</li> </ul> At that point, you are already rebuilding a formal system. <hr> <h2 id="languages-are-formal-systems"> Languages Are Formal Systems <a class="heading-link" href="#languages-are-formal-systems"> Link to heading </a> </h2> Languages: <ul> <li>Are minimal</li> <li>Are precise</li> <li>Can be syntactically close to natural language</li> <li>Support deterministic navigation</li> <li>Enable runtime introspection (autocomplete, discovery)</li> </ul> Most importantly: Languages allow relational identification. Objects are identified not by name alone, but by their position in a capability topology. This is strictly stronger than nominal invocation. <hr> <h2 id="relational-navigation-beats-nominal-invocation"> Relational Navigation Beats Nominal Invocation <a class="heading-link" href="#relational-navigation-beats-nominal-invocation"> Link to heading </a> </h2> LLMs are good at resolving names. They are bad at: <ul> <li>Systematic search</li> <li>Relational exploration</li> <li>Topological disambiguation</li> </ul> A formal language enables: <ul> <li>Search through capability graphs</li> <li>Context-aware narrowing</li> <li>Progressive discovery</li> <li>Authorization by construction</li> </ul> This is not “autocomplete”. This is relational observation over a formal structure. <hr> <h2 id="the-implementation-is-already-known"> The Implementation Is Already Known <a class="heading-link" href="#the-implementation-is-already-known"> Link to heading </a> </h2> Asynchronous parsing is not new. Generators: <ul> <li>Exist in JavaScript for over a decade</li> <li>Are foundational in operating systems</li> <li>Are widely used in parsers and schedulers</li> </ul> They are exactly the right abstraction: <ul> <li>Incremental</li> <li>Stateful</li> <li>Deterministic</li> <li>Interruptible</li> </ul> Nothing exotic is required. <hr> <h2 id="the-critical-difference"> The Critical Difference <a class="heading-link" href="#the-critical-difference"> Link to heading </a> </h2> The most important outcome of such a system is this: It can correctly deny you access. This places it in a completely different category than LLM-driven systems. LLMs aim to be helpful. Formal systems aim to be correct. When invoking real capabilities, correctness wins. <hr> <h2 id="closing"> Closing <a class="heading-link" href="#closing"> Link to heading </a> </h2> Dynamically generated languages and centralized capability graphs solve the same class of problems as MCP servers. They do so: <ul> <li>Deterministically</li> <li>Safely</li> <li>Transparently</li> <li>With better UX</li> <li>And with lower long-term complexity</li> </ul> This is not the future of “AI interfaces”. This is the future of intent architecture. <h1 id="dynamically-generated-languages-solve-the-same-class-of-problems-as-mcp-servers--and-do-it-better"> Dynamically Generated Languages Solve the Same Class of Problems as MCP Servers — and Do It Better <a class="heading-link" href="#dynamically-generated-languages-solve-the-same-class-of-problems-as-mcp-servers--and-do-it-better"> Link to heading </a> </h1> After battle-testing these ideas in practice, here is my conclusion: Centralized interaction and intent architectures are inevitable. The only real question is whether we build them as formal systems or probabilistic agents. <hr> <h2 id="from-clicking-and-scrolling-to-invoking-capabilities"> From Clicking and Scrolling to Invoking Capabilities <a class="heading-link" href="#from-clicking-and-scrolling-to-invoking-capabilities"> Link to heading </a> </h2> User interaction is moving away from clicking and scrolling and toward invoking capabilities directly, most notably via voice. This shift is powerful: <ul> <li>If you can name a capability, you can invoke it</li> <li>Interaction becomes direct</li> <li>UX complexity drops dramatically</li> </ul> From a UX-complexity standpoint, this is a clear win. However, this change forces a fundamental architectural shift compared to traditional frontend setups. <hr> <h2 id="react-and-the-problem-of-distributed-capabilities"> React and the Problem of Distributed Capabilities <a class="heading-link" href="#react-and-the-problem-of-distributed-capabilities"> Link to heading </a> </h2> Consider a typical React application. In React: <ul> <li>Capabilities are exposed through components</li> <li>Components expose behavior via props and callbacks</li> <li>Capabilities are therefore distributed by construction</li> </ul> There is no centralized place where “what the system can do” exists. Trying to centralize this in React quickly reveals deep friction: <ul> <li>Hooks produce unstable references across renders</li> <li>Central registries must constantly re-register handlers</li> <li>Context-based solutions become brittle and stateful</li> <li>Unsubscribing DOM listeners requires the exact same function reference</li> <li>That reference is often no longer available or stable</li> </ul> Yes, you can build a capability registry on top of React. But it is: <ul> <li>Clunky</li> <li>Hard to reason about</li> <li>Tightly coupled to rendering lifecycle</li> <li>Architecturally inverted</li> </ul> All of this is a strong signal: centralized capability invocation does not belong inside the UI layer. <hr> <h2 id="centralization-is-not-optional"> Centralization Is Not Optional <a class="heading-link" href="#centralization-is-not-optional"> Link to heading </a> </h2> Now compare this with a system like the Visual Studio Code command palette. VS Code exposes: <ul> <li>A centralized</li> <li>Runtime-configurable</li> <li>Discoverable</li> <li>Uniform command surface</li> </ul> Once a command is registered: <ul> <li>It does not matter where it lives</li> <li>It does not matter which UI triggered it</li> <li>It can be invoked uniformly</li> </ul> This is not an accident. It is a capability-first architecture. <hr> <h2 id="the-natural-conclusion-a-decoupled-capability-layer"> The Natural Conclusion: A Decoupled Capability Layer <a class="heading-link" href="#the-natural-conclusion-a-decoupled-capability-layer"> Link to heading </a> </h2> What naturally follows is a module that: <ul> <li>Is decoupled from the frontend</li> <li>Has no dependency on UI frameworks</li> <li>Accepts voice or textual input</li> <li>Emits discrete, authorized commands</li> </ul> At first glance, this smells like parsing. And that is exactly what it is — with one important caveat. <hr> <h2 id="this-is-parsing--not-ai"> This Is Parsing — Not AI <a class="heading-link" href="#this-is-parsing--not-ai"> Link to heading </a> </h2> Traditional parsing assumes: <ul> <li>Full input available upfront</li> <li>A lexing phase</li> <li>A parsing phase</li> <li>A final AST</li> </ul> User interaction does not work this way. For voice and interactive input we need: <ul> <li>Incremental parsing</li> <li>Partial feedback</li> <li>Real-time guidance</li> <li>Asynchronous evaluation</li> </ul> This is not AI. This is asynchronous parsing. That distinction matters. <hr> <h2 id="mcp-servers-and-the-core-problem"> MCP Servers and the Core Problem <a class="heading-link" href="#mcp-servers-and-the-core-problem"> Link to heading </a> </h2> MCP servers attempt to solve a similar problem: <ul> <li>Centralized capability invocation</li> <li>Access via natural language</li> <li>Location-agnostic execution</li> </ul> In practice: <ul> <li>Once a capability is integrated, its origin no longer matters</li> <li>If you can name it, you can invoke it</li> </ul> On the surface, this sounds ideal. It is not. <hr> <h2 id="why-informal-invocation-is-dangerous"> Why Informal Invocation Is Dangerous <a class="heading-link" href="#why-informal-invocation-is-dangerous"> Link to heading </a> </h2> MCP-style systems rely on: <ul> <li>NLP → mapping informal language to formal side effects</li> <li>Agents → which can and do hallucinate</li> </ul> This creates a fundamental mismatch: <ul> <li>Informal input</li> <li>Formal consequences</li> </ul> The moment real side effects exist, you must introduce: <ul> <li>Authorization</li> <li>Capability scoping</li> <li>Denial rules</li> <li>Auditability</li> </ul> At that point, you are already rebuilding a formal system. <hr> <h2 id="languages-are-formal-systems"> Languages Are Formal Systems <a class="heading-link" href="#languages-are-formal-systems"> Link to heading </a> </h2> Languages: <ul> <li>Are minimal</li> <li>Are precise</li> <li>Can be syntactically close to natural language</li> <li>Support deterministic navigation</li> <li>Enable runtime introspection (autocomplete, discovery)</li> </ul> Most importantly: Languages allow relational identification. Objects are identified not by name alone, but by their position in a capability topology. This is strictly stronger than nominal invocation. <hr> <h2 id="relational-navigation-beats-nominal-invocation"> Relational Navigation Beats Nominal Invocation <a class="heading-link" href="#relational-navigation-beats-nominal-invocation"> Link to heading </a> </h2> LLMs are good at resolving names. They are bad at: <ul> <li>Systematic search</li> <li>Relational exploration</li> <li>Topological disambiguation</li> </ul> A formal language enables: <ul> <li>Search through capability graphs</li> <li>Context-aware narrowing</li> <li>Progressive discovery</li> <li>Authorization by construction</li> </ul> This is not “autocomplete”. This is relational observation over a formal structure. <hr> <h2 id="the-implementation-is-already-known"> The Implementation Is Already Known <a class="heading-link" href="#the-implementation-is-already-known"> Link to heading </a> </h2> Asynchronous parsing is not new. Generators: <ul> <li>Exist in JavaScript for over a decade</li> <li>Are foundational in operating systems</li> <li>Are widely used in parsers and schedulers</li> </ul> They are exactly the right abstraction: <ul> <li>Incremental</li> <li>Stateful</li> <li>Deterministic</li> <li>Interruptible</li> </ul> Nothing exotic is required. <hr> <h2 id="the-critical-difference"> The Critical Difference <a class="heading-link" href="#the-critical-difference"> Link to heading </a> </h2> The most important outcome of such a system is this: It can correctly deny you access. This places it in a completely different category than LLM-driven systems. LLMs aim to be helpful. Formal systems aim to be correct. When invoking real capabilities, correctness wins. <hr> <h2 id="closing"> Closing <a class="heading-link" href="#closing"> Link to heading </a> </h2> Dynamically generated languages and centralized capability graphs solve the same class of problems as MCP servers. They do so: <ul> <li>Deterministically</li> <li>Safely</li> <li>Transparently</li> <li>With better UX</li> <li>And with lower long-term complexity</li> </ul> This is not the future of “AI interfaces”. This is the future of intent architecture. Automation Doesn’t Work for You – And That’s By Design https://316c0611.personalpage-ahl.pages.dev/posts/power-of-automation/ https://316c0611.personalpage-ahl.pages.dev/posts/power-of-automation/ Sat, 24 May 2025 17:10:43 +0200 <h1 id="automation-doesnt-work-for-you--and-thats-by-design"> Automation Doesn’t Work for You – And That’s By Design <a class="heading-link" href="#automation-doesnt-work-for-you--and-thats-by-design"> Link to heading </a> </h1> <blockquote> Automation is Power.</blockquote> This truth was carved into history when Alan Turing and others turned machines into war-winning tools. Those who mastered automation during wartime gained world-scale leverage. The ability to process and act faster than your enemy became the new axis of power. Such is the scale of automation. Fast-forward to today. You have more raw computational power in your pocket than Turing had in all of Bletchley Park. You have access to programming languages, cloud infrastructure, and libraries of logic once reserved for elite scientists. But power of automation doesn&rsquo;t work for you! This is the real question. Not &ldquo;will AI replace us&rdquo; junk. Why is power of automation, remember, world war scale power not working for me? Even tho you have ingredients, processing power and lets say ability to command that power - write code. Do you actually think about that? The automation dream was hijacked. You have the electricity but not the switchboard. The processor but not the interface. The AI but not the reasoning layer. Again: &ldquo;Will AI replace us?&rdquo; Don&rsquo;t you see it? Wrong question! Another promise of power which will by the mechanism that is already in place, yet again not work for you. You work for it. How? <h2 id="fragmentation-the-smoke-bomb-of-the-digital-age"> Fragmentation: The Smoke Bomb of the Digital Age <a class="heading-link" href="#fragmentation-the-smoke-bomb-of-the-digital-age"> Link to heading </a> </h2> Each wave of technology promises more power. But each wave forces you to rewrite, reintegrate, relearn. Your logic becomes disposable. Your interfaces become incompatible. Your memory becomes siloed. This is not a bug. It is a feature of fragmentation. Fragmentation is the mechanism by which systems disguise the fact that they are not automating anything. They are making you repeat the same patterns in new wrappers. Rebuilding the same UI, the same logic, the same workflows. Take the modern chat app: You cannot access your own conversations programmatically. You cannot extract patterns, memories, or trails of thought. You are locked in a scroll-and-forget interface designed to make you dependent, not aware. It is software modeled after corporate structure, not human intent. The chat box is the perfect metaphor: it simulates conversation, but blocks ownership of the knowledge. <h2 id="data-ownership-is-index-ownership"> Data Ownership Is Index Ownership <a class="heading-link" href="#data-ownership-is-index-ownership"> Link to heading </a> </h2> The true value of data is not in possession, but in referencing. If you can&rsquo;t traverse it, connect it, recall it—you don&rsquo;t own it. <blockquote> Data ownership is index ownership.</blockquote> And by design, you do not own the index. The index is hidden behind UX. The index is locked behind APIs. The index is reshuffled and monetized in feeds you can&rsquo;t control. But the index is the power of intelligence. It is what lets memory become utility. It is what makes pattern recognition possible. It is what defines reasoning. Ownership of data without the index is a decoy. A smokescreen. Post-Fragmentation Systems: Toward Real Control To reclaim power, we must move past naming, past folders, past the app paradigm. We must build systems where: Indexing is declarative, relational, and user-centric. Search becomes semantic, associative, and deterministic. Memory becomes a graph, not a graveyard. Data and instruction become one, and automation becomes aligned. This is not fantasy. It is architecture. And it is being built. Even among developers—millions of us who write the indexes—we still haven’t built a unified temple of collaboration and goodwill. Yes, we have open source. And yes, you can spin up your own chat server and inspect your own data. But even open source remains locked in the design logic of a fragmented world. There is no single monorepo of human collaboration. No shared structure of memory. No living index that binds our work together. Why? Because even in the act of programming itself, fragmentation is embedded at the root. The final tool of fragmentation is not an app, nor a UX. It is the deepest coupling in software itself—the binding of location and reference. Stay tuned. That fracture deserves a chapter of its own. <h1 id="automation-doesnt-work-for-you--and-thats-by-design"> Automation Doesn’t Work for You – And That’s By Design <a class="heading-link" href="#automation-doesnt-work-for-you--and-thats-by-design"> Link to heading </a> </h1> <blockquote> Automation is Power.</blockquote> This truth was carved into history when Alan Turing and others turned machines into war-winning tools. Those who mastered automation during wartime gained world-scale leverage. The ability to process and act faster than your enemy became the new axis of power. Such is the scale of automation. Fast-forward to today. You have more raw computational power in your pocket than Turing had in all of Bletchley Park. You have access to programming languages, cloud infrastructure, and libraries of logic once reserved for elite scientists. But power of automation doesn&rsquo;t work for you! This is the real question. Not &ldquo;will AI replace us&rdquo; junk. Why is power of automation, remember, world war scale power not working for me? Even tho you have ingredients, processing power and lets say ability to command that power - write code. Do you actually think about that? The automation dream was hijacked. You have the electricity but not the switchboard. The processor but not the interface. The AI but not the reasoning layer. Again: &ldquo;Will AI replace us?&rdquo; Don&rsquo;t you see it? Wrong question! Another promise of power which will by the mechanism that is already in place, yet again not work for you. You work for it. How? <h2 id="fragmentation-the-smoke-bomb-of-the-digital-age"> Fragmentation: The Smoke Bomb of the Digital Age <a class="heading-link" href="#fragmentation-the-smoke-bomb-of-the-digital-age"> Link to heading </a> </h2> Each wave of technology promises more power. But each wave forces you to rewrite, reintegrate, relearn. Your logic becomes disposable. Your interfaces become incompatible. Your memory becomes siloed. This is not a bug. It is a feature of fragmentation. Fragmentation is the mechanism by which systems disguise the fact that they are not automating anything. They are making you repeat the same patterns in new wrappers. Rebuilding the same UI, the same logic, the same workflows. Take the modern chat app: You cannot access your own conversations programmatically. You cannot extract patterns, memories, or trails of thought. You are locked in a scroll-and-forget interface designed to make you dependent, not aware. It is software modeled after corporate structure, not human intent. The chat box is the perfect metaphor: it simulates conversation, but blocks ownership of the knowledge. <h2 id="data-ownership-is-index-ownership"> Data Ownership Is Index Ownership <a class="heading-link" href="#data-ownership-is-index-ownership"> Link to heading </a> </h2> The true value of data is not in possession, but in referencing. If you can&rsquo;t traverse it, connect it, recall it—you don&rsquo;t own it. <blockquote> Data ownership is index ownership.</blockquote> And by design, you do not own the index. The index is hidden behind UX. The index is locked behind APIs. The index is reshuffled and monetized in feeds you can&rsquo;t control. But the index is the power of intelligence. It is what lets memory become utility. It is what makes pattern recognition possible. It is what defines reasoning. Ownership of data without the index is a decoy. A smokescreen. Post-Fragmentation Systems: Toward Real Control To reclaim power, we must move past naming, past folders, past the app paradigm. We must build systems where: Indexing is declarative, relational, and user-centric. Search becomes semantic, associative, and deterministic. Memory becomes a graph, not a graveyard. Data and instruction become one, and automation becomes aligned. This is not fantasy. It is architecture. And it is being built. Even among developers—millions of us who write the indexes—we still haven’t built a unified temple of collaboration and goodwill. Yes, we have open source. And yes, you can spin up your own chat server and inspect your own data. But even open source remains locked in the design logic of a fragmented world. There is no single monorepo of human collaboration. No shared structure of memory. No living index that binds our work together. Why? Because even in the act of programming itself, fragmentation is embedded at the root. The final tool of fragmentation is not an app, nor a UX. It is the deepest coupling in software itself—the binding of location and reference. Stay tuned. That fracture deserves a chapter of its own. FP vs IP and Microservices vs Monoliths are the same argument https://316c0611.personalpage-ahl.pages.dev/posts/recomputing-since-christ/ https://316c0611.personalpage-ahl.pages.dev/posts/recomputing-since-christ/ Thu, 15 May 2025 17:10:43 +0200 <h1 id="fp-vs-ip-and-microservices-vs-monoliths-are-the-same-argument"> FP vs IP and Microservices vs Monoliths are the same argument <a class="heading-link" href="#fp-vs-ip-and-microservices-vs-monoliths-are-the-same-argument"> Link to heading </a> </h1> There is a huge parallel between: <ul> <li>functional vs imperative programming</li> <li>microservices vs monoliths</li> </ul> Now, the most unwelcome thing—dogma—should have no foothold in the software world. But it does. Just like other markets, we ride waves of virality. It’s no coincidence that most beginners choose the most popular frameworks and languages. While this kind of marketing gives guidance, it destroys the very essence of what coding should be: sense. So parrots fly around and repeat things like: <ul> <li>&ldquo;Microservices are better than monoliths&rdquo;</li> <li>&ldquo;Functional programming is better than imperative programming&rdquo;</li> </ul> But both approaches live, both are used—and that alone tells us both are good and both have their place. Let’s draw the parallel between these two debates and expose the hype for what it is. <hr> <h2 id="the-microservice-hype"> The Microservice Hype <a class="heading-link" href="#the-microservice-hype"> Link to heading </a> </h2> Every aspiring developer is told they must know how to build scalable systems before they can land a job—as if each of us is building cloud-scale infrastructure for side projects. Buzzwords in job postings feed the hype, and so do slogans like: <ul> <li>“Your microservice team can be fed by one pizza.”</li> <li>“Keep your services stateless.”</li> </ul> How many times have I heard the second one in interviews—only to open the source code and find a constructor call inside a <code>get</code> method, of a class passed via dependency injection&hellip; in JavaScript. Come on. Time to quit (this really happened 😅). <hr> <h2 id="java-overengineering-in-javascript"> Java Overengineering in JavaScript <a class="heading-link" href="#java-overengineering-in-javascript"> Link to heading </a> </h2> Java-style overengineering doesn’t belong in JavaScript. <ul> <li>Your JS module is automatically a singleton (unless you use dynamic imports).</li> <li>The runtime handles circular dependency resolution.</li> <li>Your module’s global-scope variables can’t be mutated from the outside without you exposing an interface to do so.</li> </ul> And yet, people bring Java complexity patterns into JS like it&rsquo;s a rite of passage. <hr> <h2 id="bitter-sweet-reality"> Bitter sweet reality <a class="heading-link" href="#bitter-sweet-reality"> Link to heading </a> </h2> This brings us to the real point: most devs are beginners. This will always be true. Most of us are territorial (we defend our code even when it sucks), and many are driven by the desire to be right—or at least to appear smart. This, combined with a general lack of experience, makes it almost a rule: large codebases will be colored with smells. Even &ldquo;stateless&rdquo; microservices often use stateful libraries or sessions for auth. Perspective is lacking—and that lack is guarded by dogma, which ultimately reduces to social behavior. And maybe that’s fine. After all, every problem should’ve been solved yesterday. Business doesn’t wait. We must deliver. Fast. So there’s no time for: <blockquote> &ldquo;If you want to make pasta from scratch, you must first invent the universe.&rdquo; — Carl Sagan</blockquote> <hr> <h2 id="services-should-be-focused"> Services Should Be Focused <a class="heading-link" href="#services-should-be-focused"> Link to heading </a> </h2> Like modules, services should focus on one thing and do it well. Why? So we can scale them horizontally, reuse them, and maintain them independently. But here’s where inexperience hits. Many devs—even seniors in web—have never written a proper multithreaded program. Those who have know that orchestrating multiple clones of the same thing requires overhead. In microservices, this overhead is primarily the cost of statelessness. <hr> <h2 id="stateless-by-design--and-by-cost"> Stateless by Design — and by Cost <a class="heading-link" href="#stateless-by-design--and-by-cost"> Link to heading </a> </h2> Your message queues, Redis instances, and storage layers all need to be stateless (or used in a stateless way), because synchronizing across clones goes against horizontal scaling. Need more performance? Spin up more instances. The more instances you have, the harder it gets to synchronize them. So… just don’t. <ul> <li>Don’t cache.</li> <li>Don’t store session data.</li> <li>Don’t share memory.</li> </ul> Instead: recompute everything every time. Just like how a server-side page is re-rendered per request. <hr> <h2 id="example"> Example <a class="heading-link" href="#example"> Link to heading </a> </h2> Let’s put it in beginner-friendly terms. Say you have a function: <div class="highlight"><pre tabindex="0" style="color:#e6edf3;background-color:#0d1117;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-python" data-lang="python">def fibonacci(n): </code></pre></div>Now you call: <div class="highlight"><pre tabindex="0" style="color:#e6edf3;background-color:#0d1117;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-python" data-lang="python">print(fibonacci(100)) print(fibonacci(101)) </code></pre></div>Neither functional programming nor microservices care that you just computed fibonacci(100). On line two, you start from scratch. Only difference? A microservice wraps it in an HTTP request. So the real question becomes: Why is this better than a monolith? Why is it better than imperative code that could just cache the result—scaling vertically and holding runtime state with ease? <blockquote> “Devs can think much further than they can code. Power to express oneself is lacking.”</blockquote> This is the key. Recomputing is obviously more expensive than caching, from the machine’s perspective. But from the developer’s perspective? Caching is low-level. Tedious. Demanding. Often lacking expressive power. So we avoid it. Instead, we build massive CI pipelines, spin nuclear-scale infrastructure, and recompute everything since Christ—just to avoid managing memory. <h2 id="scaling-with-clones-vs-standing-on-state"> Scaling with Clones vs Standing on State <a class="heading-link" href="#scaling-with-clones-vs-standing-on-state"> Link to heading </a> </h2> Functional programming and microservices recompute anew—but can easily spawn 1000 instances of the same thing. Imperative programming and monoliths tend to revolve around a single instance—but with the benefit of retained state and optimized memory usage. Which one is better? No straight answer. <h2 id="protecting-the-codebase-from-your-own-team"> Protecting the Codebase from Your Own Team <a class="heading-link" href="#protecting-the-codebase-from-your-own-team"> Link to heading </a> </h2> If you have a large team, you often want to restrict expressive power. You narrow responsibilities so each dev works in isolation. This reduces risk, reduces damage, and speeds up onboarding. Yes, expressive power is linked to production cost and complexity. And industry cares more about delivering features than squeezing performance. Under one condition: <h2 id="platforms-vs-applications"> Platforms vs Applications <a class="heading-link" href="#platforms-vs-applications"> Link to heading </a> </h2> We can divide software into two rough categories: <ul> <li>Infrastructure — platforms like compilers, browsers, frameworks, and libraries</li> <li>Applications — business logic and user-facing systems</li> </ul> If you fall into the second category, you tend to value: Expressive power Fast iteration High-level abstraction That’s when you lean on frameworks, CI pipelines, and horizontal scaling. But if you&rsquo;re building infrastructure, you care more about: Precision Performance Long-term stability So you optimize. You profile. You write tight, efficient code. <h2 id="the-pendulum-swings"> The Pendulum Swings <a class="heading-link" href="#the-pendulum-swings"> Link to heading </a> </h2> We can’t always compute exactly when it’s time to switch paradigms. When is it worth optimizing that slow service? When is it better to lean into scale? The pendulum will keep swinging—from monolith to microservice, from FP to imperative. But the ideal gap between what we can think and what we can express in code is still wide. Maybe unbridgeable. <h2 id="the-real-limitation-human-abstraction"> The Real Limitation: Human Abstraction <a class="heading-link" href="#the-real-limitation-human-abstraction"> Link to heading </a> </h2> It’s not that we lack tools to build expressive languages. They exist. The real problem is: Human limitations in abstraction. As one of my respected colleagues once said: “The more abstract you go, the more language resembles static noise.” And that is something worth pondering. It may be the real cause behind these never-ending clashes in modern software: FP vs IP, MS vs monolith — and the limits of the human mind behind the keyboard. <h1 id="fp-vs-ip-and-microservices-vs-monoliths-are-the-same-argument"> FP vs IP and Microservices vs Monoliths are the same argument <a class="heading-link" href="#fp-vs-ip-and-microservices-vs-monoliths-are-the-same-argument"> Link to heading </a> </h1> There is a huge parallel between: <ul> <li>functional vs imperative programming</li> <li>microservices vs monoliths</li> </ul> Now, the most unwelcome thing—dogma—should have no foothold in the software world. But it does. Just like other markets, we ride waves of virality. It’s no coincidence that most beginners choose the most popular frameworks and languages. While this kind of marketing gives guidance, it destroys the very essence of what coding should be: sense. So parrots fly around and repeat things like: <ul> <li>&ldquo;Microservices are better than monoliths&rdquo;</li> <li>&ldquo;Functional programming is better than imperative programming&rdquo;</li> </ul> But both approaches live, both are used—and that alone tells us both are good and both have their place. Let’s draw the parallel between these two debates and expose the hype for what it is. <hr> <h2 id="the-microservice-hype"> The Microservice Hype <a class="heading-link" href="#the-microservice-hype"> Link to heading </a> </h2> Every aspiring developer is told they must know how to build scalable systems before they can land a job—as if each of us is building cloud-scale infrastructure for side projects. Buzzwords in job postings feed the hype, and so do slogans like: <ul> <li>“Your microservice team can be fed by one pizza.”</li> <li>“Keep your services stateless.”</li> </ul> How many times have I heard the second one in interviews—only to open the source code and find a constructor call inside a <code>get</code> method, of a class passed via dependency injection&hellip; in JavaScript. Come on. Time to quit (this really happened 😅). <hr> <h2 id="java-overengineering-in-javascript"> Java Overengineering in JavaScript <a class="heading-link" href="#java-overengineering-in-javascript"> Link to heading </a> </h2> Java-style overengineering doesn’t belong in JavaScript. <ul> <li>Your JS module is automatically a singleton (unless you use dynamic imports).</li> <li>The runtime handles circular dependency resolution.</li> <li>Your module’s global-scope variables can’t be mutated from the outside without you exposing an interface to do so.</li> </ul> And yet, people bring Java complexity patterns into JS like it&rsquo;s a rite of passage. <hr> <h2 id="bitter-sweet-reality"> Bitter sweet reality <a class="heading-link" href="#bitter-sweet-reality"> Link to heading </a> </h2> This brings us to the real point: most devs are beginners. This will always be true. Most of us are territorial (we defend our code even when it sucks), and many are driven by the desire to be right—or at least to appear smart. This, combined with a general lack of experience, makes it almost a rule: large codebases will be colored with smells. Even &ldquo;stateless&rdquo; microservices often use stateful libraries or sessions for auth. Perspective is lacking—and that lack is guarded by dogma, which ultimately reduces to social behavior. And maybe that’s fine. After all, every problem should’ve been solved yesterday. Business doesn’t wait. We must deliver. Fast. So there’s no time for: <blockquote> &ldquo;If you want to make pasta from scratch, you must first invent the universe.&rdquo; — Carl Sagan</blockquote> <hr> <h2 id="services-should-be-focused"> Services Should Be Focused <a class="heading-link" href="#services-should-be-focused"> Link to heading </a> </h2> Like modules, services should focus on one thing and do it well. Why? So we can scale them horizontally, reuse them, and maintain them independently. But here’s where inexperience hits. Many devs—even seniors in web—have never written a proper multithreaded program. Those who have know that orchestrating multiple clones of the same thing requires overhead. In microservices, this overhead is primarily the cost of statelessness. <hr> <h2 id="stateless-by-design--and-by-cost"> Stateless by Design — and by Cost <a class="heading-link" href="#stateless-by-design--and-by-cost"> Link to heading </a> </h2> Your message queues, Redis instances, and storage layers all need to be stateless (or used in a stateless way), because synchronizing across clones goes against horizontal scaling. Need more performance? Spin up more instances. The more instances you have, the harder it gets to synchronize them. So… just don’t. <ul> <li>Don’t cache.</li> <li>Don’t store session data.</li> <li>Don’t share memory.</li> </ul> Instead: recompute everything every time. Just like how a server-side page is re-rendered per request. <hr> <h2 id="example"> Example <a class="heading-link" href="#example"> Link to heading </a> </h2> Let’s put it in beginner-friendly terms. Say you have a function: <div class="highlight"><pre tabindex="0" style="color:#e6edf3;background-color:#0d1117;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-python" data-lang="python">def fibonacci(n): </code></pre></div>Now you call: <div class="highlight"><pre tabindex="0" style="color:#e6edf3;background-color:#0d1117;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-python" data-lang="python">print(fibonacci(100)) print(fibonacci(101)) </code></pre></div>Neither functional programming nor microservices care that you just computed fibonacci(100). On line two, you start from scratch. Only difference? A microservice wraps it in an HTTP request. So the real question becomes: Why is this better than a monolith? Why is it better than imperative code that could just cache the result—scaling vertically and holding runtime state with ease? <blockquote> “Devs can think much further than they can code. Power to express oneself is lacking.”</blockquote> This is the key. Recomputing is obviously more expensive than caching, from the machine’s perspective. But from the developer’s perspective? Caching is low-level. Tedious. Demanding. Often lacking expressive power. So we avoid it. Instead, we build massive CI pipelines, spin nuclear-scale infrastructure, and recompute everything since Christ—just to avoid managing memory. <h2 id="scaling-with-clones-vs-standing-on-state"> Scaling with Clones vs Standing on State <a class="heading-link" href="#scaling-with-clones-vs-standing-on-state"> Link to heading </a> </h2> Functional programming and microservices recompute anew—but can easily spawn 1000 instances of the same thing. Imperative programming and monoliths tend to revolve around a single instance—but with the benefit of retained state and optimized memory usage. Which one is better? No straight answer. <h2 id="protecting-the-codebase-from-your-own-team"> Protecting the Codebase from Your Own Team <a class="heading-link" href="#protecting-the-codebase-from-your-own-team"> Link to heading </a> </h2> If you have a large team, you often want to restrict expressive power. You narrow responsibilities so each dev works in isolation. This reduces risk, reduces damage, and speeds up onboarding. Yes, expressive power is linked to production cost and complexity. And industry cares more about delivering features than squeezing performance. Under one condition: <h2 id="platforms-vs-applications"> Platforms vs Applications <a class="heading-link" href="#platforms-vs-applications"> Link to heading </a> </h2> We can divide software into two rough categories: <ul> <li>Infrastructure — platforms like compilers, browsers, frameworks, and libraries</li> <li>Applications — business logic and user-facing systems</li> </ul> If you fall into the second category, you tend to value: Expressive power Fast iteration High-level abstraction That’s when you lean on frameworks, CI pipelines, and horizontal scaling. But if you&rsquo;re building infrastructure, you care more about: Precision Performance Long-term stability So you optimize. You profile. You write tight, efficient code. <h2 id="the-pendulum-swings"> The Pendulum Swings <a class="heading-link" href="#the-pendulum-swings"> Link to heading </a> </h2> We can’t always compute exactly when it’s time to switch paradigms. When is it worth optimizing that slow service? When is it better to lean into scale? The pendulum will keep swinging—from monolith to microservice, from FP to imperative. But the ideal gap between what we can think and what we can express in code is still wide. Maybe unbridgeable. <h2 id="the-real-limitation-human-abstraction"> The Real Limitation: Human Abstraction <a class="heading-link" href="#the-real-limitation-human-abstraction"> Link to heading </a> </h2> It’s not that we lack tools to build expressive languages. They exist. The real problem is: Human limitations in abstraction. As one of my respected colleagues once said: “The more abstract you go, the more language resembles static noise.” And that is something worth pondering. It may be the real cause behind these never-ending clashes in modern software: FP vs IP, MS vs monolith — and the limits of the human mind behind the keyboard.