System Design · djuleayo

System Design · djuleayo https://316c0611.personalpage-ahl.pages.dev/tags/system-design/ Hugo en Why You Must Revisit the Stack Data Structure in the Age of AI https://316c0611.personalpage-ahl.pages.dev/posts/stack-importance/ https://316c0611.personalpage-ahl.pages.dev/posts/stack-importance/ Sat, 24 Jan 2026 09:22:50 +0200 <h1 id="why-you-must-revisit-the-stack-data-structure-in-the-age-of-ai"> Why You Must Revisit the Stack Data Structure in the Age of AI <a class="heading-link" href="#why-you-must-revisit-the-stack-data-structure-in-the-age-of-ai"> Link to heading </a> </h1> With the rise of AI-assisted coding, execution has become cheap. You can let the AI do the wiring. What you cannot delegate is the choice of abstractions. And that changes everything. If you choose the right abstractions, your system scales. If you don’t, you don’t get “bad code” — you get semantic debt: a pile of spaghetti whose behavior you no longer understand. That’s why data structures matter more today than they did before. Not because you must be able to implement them, but because you must understand the semantic consequences of choosing one. Those consequences often cascade far beyond what you intended. Let’s see this with the simplest example possible. <hr> <h2 id="the-stack-is-not-just-a-stack"> The Stack Is Not Just a Stack <a class="heading-link" href="#the-stack-is-not-just-a-stack"> Link to heading </a> </h2> A stack is one of the simplest data structures we have. So simple, in fact, that it exists physically in hardware. <ul> <li>CPUs implement stack pointers</li> <li>Operating systems allocate a stack per process</li> <li>Languages expose it implicitly via function calls and scopes</li> </ul> In C-like languages, opening a <code>{}</code> opens a stack frame. When you exceed stack memory, the OS kills your program. Even Stack Overflow is named after this exact failure mode. You cannot write a program without a stack. So far, nothing surprising. But now track execution mentally. If function <code>A</code> calls <code>B</code>, and then <code>C</code>, execution looks like this: <ul> <li>Enter <code>A</code></li> <li>Enter <code>B</code></li> <li>Exit <code>B</code></li> <li>Enter <code>C</code></li> <li>Exit <code>C</code></li> <li>Exit <code>A</code></li> </ul> At runtime, the stack is a path. But over time, the trace of execution forms a tree: <ul> <li><code>A</code> is the parent</li> <li><code>B</code> and <code>C</code> are siblings</li> </ul> The stack is not “just LIFO”. It is a traversal of a tree-shaped execution history. This matters more than most developers realize. <hr> <h2 id="execution-leaves-a-shape"> Execution Leaves a Shape <a class="heading-link" href="#execution-leaves-a-shape"> Link to heading </a> </h2> Most developers are comfortable with stack behavior. Far fewer are comfortable with closures — and this is why. Closures break the illusion that execution is only a stack. Consider this example: <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-ts" data-lang="ts">const makeClosure = () =&gt; { let a = 10; function closure() { console.log(a); } return closure; }; const myClosure = makeClosure(); myClosure(); // prints 10 </code></pre></div>Here’s the puzzle: <ul> <li>makeClosure() creates a stack frame</li> <li>That stack frame exits</li> <li>Yet a is still accessible later</li> </ul> So where is <code>a</code>? It cannot be on the stack. The stack frame is gone. The only possible conclusion: execution is no longer a simple stack. What actually happens is this: <ul> <li>The stack is one branch of a larger execution tree</li> <li>Closures preserve parts of that tree after the branch collapses</li> <li>Variables escape time, not scope</li> </ul> Once you understand this, async functions, promises, callbacks, and event-driven runtimes stop feeling magical. They are not “stack tricks”. They are graph-shaped execution. <h2 id="why-you-should-care"> Why You Should Care <a class="heading-link" href="#why-you-should-care"> Link to heading </a> </h2> In an age where any of us can spin up a workforce in the form of AI agents, the real challenge is no longer writing code — it’s scaling systems. People sense this intuitively. That’s why they keep building frameworks, layers, and tooling with increasing internal complexity. Frameworks consume your code — or AI-generated wiring — and impose their own abstractions and limitations. That is precisely where architectural decisions become irreversible. Here’s the key point: Seeing the stack as the active trunk of an execution tree is the mental model behind virtual machines, language runtimes, and frameworks themselves. If you don’t understand the semantic consequences of your data structures, you are outsourcing architecture to tools that don’t pay the cost when things go wrong. I’ll write more about this using concrete examples from a VM I built using exactly this perspective. As a preview: it supports async pipelines natively — but more on that later. <h1 id="why-you-must-revisit-the-stack-data-structure-in-the-age-of-ai"> Why You Must Revisit the Stack Data Structure in the Age of AI <a class="heading-link" href="#why-you-must-revisit-the-stack-data-structure-in-the-age-of-ai"> Link to heading </a> </h1> With the rise of AI-assisted coding, execution has become cheap. You can let the AI do the wiring. What you cannot delegate is the choice of abstractions. And that changes everything. If you choose the right abstractions, your system scales. If you don’t, you don’t get “bad code” — you get semantic debt: a pile of spaghetti whose behavior you no longer understand. That’s why data structures matter more today than they did before. Not because you must be able to implement them, but because you must understand the semantic consequences of choosing one. Those consequences often cascade far beyond what you intended. Let’s see this with the simplest example possible. <hr> <h2 id="the-stack-is-not-just-a-stack"> The Stack Is Not Just a Stack <a class="heading-link" href="#the-stack-is-not-just-a-stack"> Link to heading </a> </h2> A stack is one of the simplest data structures we have. So simple, in fact, that it exists physically in hardware. <ul> <li>CPUs implement stack pointers</li> <li>Operating systems allocate a stack per process</li> <li>Languages expose it implicitly via function calls and scopes</li> </ul> In C-like languages, opening a <code>{}</code> opens a stack frame. When you exceed stack memory, the OS kills your program. Even Stack Overflow is named after this exact failure mode. You cannot write a program without a stack. So far, nothing surprising. But now track execution mentally. If function <code>A</code> calls <code>B</code>, and then <code>C</code>, execution looks like this: <ul> <li>Enter <code>A</code></li> <li>Enter <code>B</code></li> <li>Exit <code>B</code></li> <li>Enter <code>C</code></li> <li>Exit <code>C</code></li> <li>Exit <code>A</code></li> </ul> At runtime, the stack is a path. But over time, the trace of execution forms a tree: <ul> <li><code>A</code> is the parent</li> <li><code>B</code> and <code>C</code> are siblings</li> </ul> The stack is not “just LIFO”. It is a traversal of a tree-shaped execution history. This matters more than most developers realize. <hr> <h2 id="execution-leaves-a-shape"> Execution Leaves a Shape <a class="heading-link" href="#execution-leaves-a-shape"> Link to heading </a> </h2> Most developers are comfortable with stack behavior. Far fewer are comfortable with closures — and this is why. Closures break the illusion that execution is only a stack. Consider this example: <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-ts" data-lang="ts">const makeClosure = () =&gt; { let a = 10; function closure() { console.log(a); } return closure; }; const myClosure = makeClosure(); myClosure(); // prints 10 </code></pre></div>Here’s the puzzle: <ul> <li>makeClosure() creates a stack frame</li> <li>That stack frame exits</li> <li>Yet a is still accessible later</li> </ul> So where is <code>a</code>? It cannot be on the stack. The stack frame is gone. The only possible conclusion: execution is no longer a simple stack. What actually happens is this: <ul> <li>The stack is one branch of a larger execution tree</li> <li>Closures preserve parts of that tree after the branch collapses</li> <li>Variables escape time, not scope</li> </ul> Once you understand this, async functions, promises, callbacks, and event-driven runtimes stop feeling magical. They are not “stack tricks”. They are graph-shaped execution. <h2 id="why-you-should-care"> Why You Should Care <a class="heading-link" href="#why-you-should-care"> Link to heading </a> </h2> In an age where any of us can spin up a workforce in the form of AI agents, the real challenge is no longer writing code — it’s scaling systems. People sense this intuitively. That’s why they keep building frameworks, layers, and tooling with increasing internal complexity. Frameworks consume your code — or AI-generated wiring — and impose their own abstractions and limitations. That is precisely where architectural decisions become irreversible. Here’s the key point: Seeing the stack as the active trunk of an execution tree is the mental model behind virtual machines, language runtimes, and frameworks themselves. If you don’t understand the semantic consequences of your data structures, you are outsourcing architecture to tools that don’t pay the cost when things go wrong. I’ll write more about this using concrete examples from a VM I built using exactly this perspective. As a preview: it supports async pipelines natively — but more on that later. 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. Service as Architecture Reversal https://316c0611.personalpage-ahl.pages.dev/posts/service-as-architecture-reversal/ https://316c0611.personalpage-ahl.pages.dev/posts/service-as-architecture-reversal/ Mon, 12 Jan 2026 09:22:50 +0200 <h1 id="service-as-architecture-reversal"> Service as Architecture Reversal <a class="heading-link" href="#service-as-architecture-reversal"> Link to heading </a> </h1> In the early internet, the intent was simple: distribute textual files with minimal markup. To support this, a client–server architecture was adopted. The naming was not accidental. A server served. The client was the master. The server could not act unless requested. It could not speak unless spoken to. This asymmetry was a core design principle of the internet. Today, our intuition feels inverted. We scroll. We are notified. We are fed. It feels as if we are no longer the masters of the system, but its dependents. How did this reversal happen? <h2 id="capability"> Capability <a class="heading-link" href="#capability"> Link to heading </a> </h2> A service exposes a capability. Take a barber. A haircut is a convenience — until you cannot cut your own hair. At that point, convenience becomes dependency. The moment you lose capability, the service becomes a control surface. This is exactly what happened to software. Software as a Service is an architectural reversal: instead of software serving on request, access to capability itself is mediated. You no longer act directly. You must go through the service. <h2 id="control-surfaces"> Control Surfaces <a class="heading-link" href="#control-surfaces"> Link to heading </a> </h2> Consider a simple example: taking a screenshot in WhatsApp. <ul> <li>You own the hardware.</li> <li>The hardware is capable.</li> <li>The action is legal.</li> <li>You want to do it.</li> </ul> Yet you cannot. The application forbids it. And who grants the application that authority? The operating system. This is the root. Modern operating systems increasingly allow applications to define rules over hardware you own. Capability is no longer assumed — it is granted. A second example is even more revealing: offline functionality. Your computer is powerful enough to edit documents, organize files, or process data locally. Yet many tools refuse to function without an internet connection. Not because computation is impossible — but because capability has been relocated behind a service boundary. When the network disappears, so does your ability to act. <h2 id="the-reversal"> The Reversal <a class="heading-link" href="#the-reversal"> Link to heading </a> </h2> Most people will never modify an operating system. They will never build tools. They will accept the service. And so the architecture completes its reversal. The system that was meant to serve becomes a gatekeeper. The user that was meant to command becomes dependent. This is not a conspiracy. It is the cumulative result of convenience traded for capability. <h2 id="resolution"> Resolution <a class="heading-link" href="#resolution"> Link to heading </a> </h2> The loss of freedom did not begin with surveillance or advertising. It began earlier — with the quiet removal of user capability. The way forward is not rejecting services. It is refusing to confuse convenience with ownership. Use services where they save time. Avoid them where they become gates. Prefer tools that work locally. Prefer systems that degrade gracefully. Prefer architectures where capability exists before permission. Because in the end, whoever holds capability holds agency. <blockquote> Freedom didn’t disappear when we were watched. It disappeared when we stopped being capable.</blockquote> <h1 id="service-as-architecture-reversal"> Service as Architecture Reversal <a class="heading-link" href="#service-as-architecture-reversal"> Link to heading </a> </h1> In the early internet, the intent was simple: distribute textual files with minimal markup. To support this, a client–server architecture was adopted. The naming was not accidental. A server served. The client was the master. The server could not act unless requested. It could not speak unless spoken to. This asymmetry was a core design principle of the internet. Today, our intuition feels inverted. We scroll. We are notified. We are fed. It feels as if we are no longer the masters of the system, but its dependents. How did this reversal happen? <h2 id="capability"> Capability <a class="heading-link" href="#capability"> Link to heading </a> </h2> A service exposes a capability. Take a barber. A haircut is a convenience — until you cannot cut your own hair. At that point, convenience becomes dependency. The moment you lose capability, the service becomes a control surface. This is exactly what happened to software. Software as a Service is an architectural reversal: instead of software serving on request, access to capability itself is mediated. You no longer act directly. You must go through the service. <h2 id="control-surfaces"> Control Surfaces <a class="heading-link" href="#control-surfaces"> Link to heading </a> </h2> Consider a simple example: taking a screenshot in WhatsApp. <ul> <li>You own the hardware.</li> <li>The hardware is capable.</li> <li>The action is legal.</li> <li>You want to do it.</li> </ul> Yet you cannot. The application forbids it. And who grants the application that authority? The operating system. This is the root. Modern operating systems increasingly allow applications to define rules over hardware you own. Capability is no longer assumed — it is granted. A second example is even more revealing: offline functionality. Your computer is powerful enough to edit documents, organize files, or process data locally. Yet many tools refuse to function without an internet connection. Not because computation is impossible — but because capability has been relocated behind a service boundary. When the network disappears, so does your ability to act. <h2 id="the-reversal"> The Reversal <a class="heading-link" href="#the-reversal"> Link to heading </a> </h2> Most people will never modify an operating system. They will never build tools. They will accept the service. And so the architecture completes its reversal. The system that was meant to serve becomes a gatekeeper. The user that was meant to command becomes dependent. This is not a conspiracy. It is the cumulative result of convenience traded for capability. <h2 id="resolution"> Resolution <a class="heading-link" href="#resolution"> Link to heading </a> </h2> The loss of freedom did not begin with surveillance or advertising. It began earlier — with the quiet removal of user capability. The way forward is not rejecting services. It is refusing to confuse convenience with ownership. Use services where they save time. Avoid them where they become gates. Prefer tools that work locally. Prefer systems that degrade gracefully. Prefer architectures where capability exists before permission. Because in the end, whoever holds capability holds agency. <blockquote> Freedom didn’t disappear when we were watched. It disappeared when we stopped being capable.</blockquote> Truth of IT, AI and sense https://316c0611.personalpage-ahl.pages.dev/posts/truth-of-it-ai-and-sense/ https://316c0611.personalpage-ahl.pages.dev/posts/truth-of-it-ai-and-sense/ Sat, 10 Jan 2026 09:22:50 +0200 <h1 id="truth-of-it-ai-and-sense"> Truth of IT, AI and sense <a class="heading-link" href="#truth-of-it-ai-and-sense"> Link to heading </a> </h1> <h2 id="it-is-power"> IT Is Power <a class="heading-link" href="#it-is-power"> Link to heading </a> </h2> <a href="https://www.djuleayo.com/posts/power-of-automation/" class="external-link" target="_blank" rel="noopener">Automation has been world-scale power since World War II.</a> AI does not change that. It only changes who can access it. Automation has never worked “for you” by default. AI will not either. The same defensive mechanisms apply. The system protects itself. Fragmentation is one of those defenses. It prevents uninvited rises to power. If you want market share, you are told you need an app on four platforms. To build that, you already need capital, distribution, and legitimacy. If you want traction, you need money. To get money, you need traction. This is not accidental. It is the essence of pyramidal systems. In any direct competition, the decisive advantage is surprise — a weapon the opponent does not expect. Markets are no different. Whether drugs, services, or software, the rule is the same: you want customers to know you exist while competitors do not. Yet newcomers are taught the opposite: build in public, share everything, come with open hands — as if power has ever been granted freely. In cultures with inherited capital and institutional trust, this illusion can survive. Elsewhere, it functions as extraction. The promise is always the same: someone won the lottery — work hard and it might be you. Cultural memory has warned about this for millennia. Prometheus was not punished for kindness, but for stealing power prematurely. Smokescreens are not moral failures. They are safeguards. Those who see them can navigate. Those who do not are filtered out. <h2 id="the-smokescreen"> The Smokescreen <a class="heading-link" href="#the-smokescreen"> Link to heading </a> </h2> This is written from nearly two decades behind a screen. For two years I was paid well to build what was, in essence, a button calling an external service. That is not a complaint. It provided time and money. Both matter. But once you build something real, you notice how aggressively usefulness is devalued. Liquidity floods products whose primary function is compliance: don’t shake the boat — you have a job. Todo apps raised billions. Not because they automate meaningfully, but because they are safe. Most “creation” today is binding: gluing together logging services, monitoring services, analytics services, translation services, storage services, auth services, payment services. What did you build? This is not laziness. It is guided behavior. Money flows steer developers away from capability and toward dependency. The web itself is structured around this principle. Now widen the lens. How many people in a country are builders by character? How many are trained as engineers? How many end up employed by foreign companies assembling SaaS stacks, mistaking API calls for ownership, platforms for infrastructure? They are not idle. They are productive — inside fragmentation. The result is predictable: local capability erodes, and sovereignty shifts to external platforms delivered “as a service.” Even technical people lose power. <a href="https://www.djuleayo.com/posts/uxmetrix/" class="external-link" target="_blank" rel="noopener">UX that is not o(1) is not automation.</a> It is control through friction. <h2 id="ai-power-redistribution"> AI Power Redistribution <a class="heading-link" href="#ai-power-redistribution"> Link to heading </a> </h2> AI changes one thing decisively: Execution is no longer the bottleneck. Coding agents, code search, and automated infrastructure inheritance remove manpower scarcity. Workforce becomes cheap. Speed becomes abundant. Capability does not. Scaling still depends on abstraction. Abstractions that can absorb exceptions without collapsing. Abstractions coherent enough to survive growth. To the unskilled eye, high-level abstraction looks like noise. Rubbish and abstraction are indistinguishable without judgment. That is the final bottleneck. As execution flattens, control passes to those who own abstractions — not organizations with headcount. Companies will depend on them, not the reverse. Not out of ideology, but out of necessity. This is not something that “must” stay so. It stays so because scaling fails without it. For the first time, mechanics are no longer the constraint. Capability is. Fragmentation declines. Coherent capability compounds. These tools being public is not generosity. It is admission. Those who can use them are rare. Those who cannot will be displaced — regardless of effort. For a builder, this shift is not motivational. It is structural. <h2 id="selection"> Selection <a class="heading-link" href="#selection"> Link to heading </a> </h2> With power comes responsibility — but responsibility is not assigned by declaration. The remaining work is not invention. It is inheritance. Understanding existing intent. Indexing accumulated systems. Maintaining coherence under growth. Very few can do this. Fewer will choose to. No invitation is required. The system selects on its own. Those who align will find leverage. Those who do not will fragment — efficiently, at scale. <h1 id="truth-of-it-ai-and-sense"> Truth of IT, AI and sense <a class="heading-link" href="#truth-of-it-ai-and-sense"> Link to heading </a> </h1> <h2 id="it-is-power"> IT Is Power <a class="heading-link" href="#it-is-power"> Link to heading </a> </h2> <a href="https://www.djuleayo.com/posts/power-of-automation/" class="external-link" target="_blank" rel="noopener">Automation has been world-scale power since World War II.</a> AI does not change that. It only changes who can access it. Automation has never worked “for you” by default. AI will not either. The same defensive mechanisms apply. The system protects itself. Fragmentation is one of those defenses. It prevents uninvited rises to power. If you want market share, you are told you need an app on four platforms. To build that, you already need capital, distribution, and legitimacy. If you want traction, you need money. To get money, you need traction. This is not accidental. It is the essence of pyramidal systems. In any direct competition, the decisive advantage is surprise — a weapon the opponent does not expect. Markets are no different. Whether drugs, services, or software, the rule is the same: you want customers to know you exist while competitors do not. Yet newcomers are taught the opposite: build in public, share everything, come with open hands — as if power has ever been granted freely. In cultures with inherited capital and institutional trust, this illusion can survive. Elsewhere, it functions as extraction. The promise is always the same: someone won the lottery — work hard and it might be you. Cultural memory has warned about this for millennia. Prometheus was not punished for kindness, but for stealing power prematurely. Smokescreens are not moral failures. They are safeguards. Those who see them can navigate. Those who do not are filtered out. <h2 id="the-smokescreen"> The Smokescreen <a class="heading-link" href="#the-smokescreen"> Link to heading </a> </h2> This is written from nearly two decades behind a screen. For two years I was paid well to build what was, in essence, a button calling an external service. That is not a complaint. It provided time and money. Both matter. But once you build something real, you notice how aggressively usefulness is devalued. Liquidity floods products whose primary function is compliance: don’t shake the boat — you have a job. Todo apps raised billions. Not because they automate meaningfully, but because they are safe. Most “creation” today is binding: gluing together logging services, monitoring services, analytics services, translation services, storage services, auth services, payment services. What did you build? This is not laziness. It is guided behavior. Money flows steer developers away from capability and toward dependency. The web itself is structured around this principle. Now widen the lens. How many people in a country are builders by character? How many are trained as engineers? How many end up employed by foreign companies assembling SaaS stacks, mistaking API calls for ownership, platforms for infrastructure? They are not idle. They are productive — inside fragmentation. The result is predictable: local capability erodes, and sovereignty shifts to external platforms delivered “as a service.” Even technical people lose power. <a href="https://www.djuleayo.com/posts/uxmetrix/" class="external-link" target="_blank" rel="noopener">UX that is not o(1) is not automation.</a> It is control through friction. <h2 id="ai-power-redistribution"> AI Power Redistribution <a class="heading-link" href="#ai-power-redistribution"> Link to heading </a> </h2> AI changes one thing decisively: Execution is no longer the bottleneck. Coding agents, code search, and automated infrastructure inheritance remove manpower scarcity. Workforce becomes cheap. Speed becomes abundant. Capability does not. Scaling still depends on abstraction. Abstractions that can absorb exceptions without collapsing. Abstractions coherent enough to survive growth. To the unskilled eye, high-level abstraction looks like noise. Rubbish and abstraction are indistinguishable without judgment. That is the final bottleneck. As execution flattens, control passes to those who own abstractions — not organizations with headcount. Companies will depend on them, not the reverse. Not out of ideology, but out of necessity. This is not something that “must” stay so. It stays so because scaling fails without it. For the first time, mechanics are no longer the constraint. Capability is. Fragmentation declines. Coherent capability compounds. These tools being public is not generosity. It is admission. Those who can use them are rare. Those who cannot will be displaced — regardless of effort. For a builder, this shift is not motivational. It is structural. <h2 id="selection"> Selection <a class="heading-link" href="#selection"> Link to heading </a> </h2> With power comes responsibility — but responsibility is not assigned by declaration. The remaining work is not invention. It is inheritance. Understanding existing intent. Indexing accumulated systems. Maintaining coherence under growth. Very few can do this. Fewer will choose to. No invitation is required. The system selects on its own. Those who align will find leverage. Those who do not will fragment — efficiently, at scale. Why I created another markup language https://316c0611.personalpage-ahl.pages.dev/posts/why-i-wrote-another-markup-language/ https://316c0611.personalpage-ahl.pages.dev/posts/why-i-wrote-another-markup-language/ Sun, 14 Sep 2025 09:22:50 +0200 Tree languages are often portrayed as pinnacle of programming capability lisp for its homoiconicity and macros prolog for its declarative nature and inference engine haskell for its purity and type system These programming languages pioneered concepts and largely influenced many. Prolog and Lisp are considered as native for AI programming. Yet amount of job ads for these converges to zero. The question is how come source of inspiration and innovation is not in wide use? How come their supperior design didnt prosper in the market? TBH I dont have definite answers. Yet I did spend a while working in these languages and I do immensely value declarative paradigm so here is my take. <ol> <li>Linguistic relativity</li> </ol> Let me set the stage real quick. That linguistic relativity thing is real. Programmers can have direct experience of how language shapes thinking. Much more so that anybody else. Transitioning from anything to prolog or haskell is exactly discovery of that impact. You change from imperative to declarative thinking. From thinking in terms of how to build something to what it is. Naming it what it is correctly brings it to existence. How its build is delegated to the language engine. <ol start="2"> <li>Escalation</li> </ol> Properties of learning a new language, be it programming or natural are reoccurring. At first you learn letters - atoms of language. Unbreakable. Then you learn words, then you learn how to hear others speak and finally you learn to express yourself. Each stage is an escalation. And dramatic one. While learning new letter system not the same as your native one it hard to imagine how could you even combine those letters into words, let alone hearing and speaking. Yet those escalations do happen in time. You can end up being expressive. Even artistically so. That escalation lets you leap worlds of difference in comparison to learning stages. And once escalation happens it rises new insights as in point 1. So lets give an example. Note is an atom. Chord is a word. Perfect hearing is language of those words. One say you cant learn perfect hearing its genetics. Others and me claim you can. There is no structural difference in escalation between letter word speaking and note chord music. One thing is missing. <ol start="3"> <li>Plasticity</li> </ol> Kids learn languages fast. It seems formulae to fast learning is proper combination of emotional engagement and structure. Beautiful. You need both hemispheres engaged and cooperating for knowledge. Exactly the ancient teaching. Kids feeling everything intensely does help in the process. Once you are in &ldquo;ive seen it all&rdquo; state, its hard to get interested let alone learn anything. You comprehend the structure just for it to evaporate. So structure, drama, sleep is the formulae. Never skip learning about personal lifes of great programmers/mathematicians etc it will give you the exact emotional engagement you need for learning. Now with some important references to language learning and relation of language and cognition we can slowly circle back to our original question. what about our 3 pivots? If point of language is escalation and expressing one self why most expressive languages are not in wide use? <ul> <li>optimizing for machine</li> <li>optimizing for fragmentation - resell same thing in different packages</li> <li>optimizing for short term gains - quick to learn, quick to deliver</li> <li>optimizing for popularity - follow trends and easy &lsquo;hello world&rsquo; examples</li> </ul> This brings us back directly to <a href="" >how automation failed us</a> We rebuild same things over and over again which is exactly what automation is not. We just do is in domain of automation machines. But this tension Tree languages are often portrayed as pinnacle of programming capability lisp for its homoiconicity and macros prolog for its declarative nature and inference engine haskell for its purity and type system These programming languages pioneered concepts and largely influenced many. Prolog and Lisp are considered as native for AI programming. Yet amount of job ads for these converges to zero. The question is how come source of inspiration and innovation is not in wide use? How come their supperior design didnt prosper in the market? TBH I dont have definite answers. Yet I did spend a while working in these languages and I do immensely value declarative paradigm so here is my take. <ol> <li>Linguistic relativity</li> </ol> Let me set the stage real quick. That linguistic relativity thing is real. Programmers can have direct experience of how language shapes thinking. Much more so that anybody else. Transitioning from anything to prolog or haskell is exactly discovery of that impact. You change from imperative to declarative thinking. From thinking in terms of how to build something to what it is. Naming it what it is correctly brings it to existence. How its build is delegated to the language engine. <ol start="2"> <li>Escalation</li> </ol> Properties of learning a new language, be it programming or natural are reoccurring. At first you learn letters - atoms of language. Unbreakable. Then you learn words, then you learn how to hear others speak and finally you learn to express yourself. Each stage is an escalation. And dramatic one. While learning new letter system not the same as your native one it hard to imagine how could you even combine those letters into words, let alone hearing and speaking. Yet those escalations do happen in time. You can end up being expressive. Even artistically so. That escalation lets you leap worlds of difference in comparison to learning stages. And once escalation happens it rises new insights as in point 1. So lets give an example. Note is an atom. Chord is a word. Perfect hearing is language of those words. One say you cant learn perfect hearing its genetics. Others and me claim you can. There is no structural difference in escalation between letter word speaking and note chord music. One thing is missing. <ol start="3"> <li>Plasticity</li> </ol> Kids learn languages fast. It seems formulae to fast learning is proper combination of emotional engagement and structure. Beautiful. You need both hemispheres engaged and cooperating for knowledge. Exactly the ancient teaching. Kids feeling everything intensely does help in the process. Once you are in &ldquo;ive seen it all&rdquo; state, its hard to get interested let alone learn anything. You comprehend the structure just for it to evaporate. So structure, drama, sleep is the formulae. Never skip learning about personal lifes of great programmers/mathematicians etc it will give you the exact emotional engagement you need for learning. Now with some important references to language learning and relation of language and cognition we can slowly circle back to our original question. what about our 3 pivots? If point of language is escalation and expressing one self why most expressive languages are not in wide use? <ul> <li>optimizing for machine</li> <li>optimizing for fragmentation - resell same thing in different packages</li> <li>optimizing for short term gains - quick to learn, quick to deliver</li> <li>optimizing for popularity - follow trends and easy &lsquo;hello world&rsquo; examples</li> </ul> This brings us back directly to <a href="" >how automation failed us</a> We rebuild same things over and over again which is exactly what automation is not. We just do is in domain of automation machines. But this tension Why I created another markup language https://316c0611.personalpage-ahl.pages.dev/posts/why-i-wrote-another-markup-language/ https://316c0611.personalpage-ahl.pages.dev/posts/why-i-wrote-another-markup-language/ Sun, 14 Sep 2025 09:22:50 +0200 <h1 id="why-i-created-new-markup-language"> Why I created new markup language? <a class="heading-link" href="#why-i-created-new-markup-language"> Link to heading </a> </h1> Yet another time to call something &ldquo;yet another&rdquo; this time it is markup language. Yet another markup language&hellip; Why? <h2 id="current"> Current <a class="heading-link" href="#current"> Link to heading </a> </h2> HTML/XML is fair example. They are in essence as simple as it gets.  All that marking up was in days of early web to state what is what in mostly textual files and allow search engines to index it properly. Later on HTML became the most coupled tech in existence having some tags with semantic meaning, some with presentation meaning and some with both, then script tags and what not. This is because it was repurposed to follow the ever growing needs of web. The fact remains, You are marking up things and in process define trees. HTML is a tree of data. So is XML. So is JSON. While I went deeper into why and when trees are insufficient in the book, here Ill go briefly. HTML anticipated these insufficiencies and decided to bridge them with anchor tags. And that is - tree simply can&rsquo;t define as much as general graph can. So instead of defining coherent/atomic units of data, reference what you need. Those familiar with graphs will immediately recognize this leads to possibility of cycles. Cycles = problems and non determinism in many cases. Or simply &ldquo;oops this page can&rsquo;t be found&rdquo; To address the central lack of trees: laying data in trees is natural when we describe single taxonomy data is often viewed in multidimensional way and tree requires proclaiming one categorization as superior which is ambiguous and not self contained All this is the setup and something I named: <blockquote> core coupling of programming</blockquote> and that is we couple address/location with reference yet it is obviously coupling of two orthogonal concepts. As proof: <ul> <li>array index is memory location and reference</li> <li>url is location and reference literally</li> <li>file path is location and reference</li> <li>variable name is location and reference</li> <li>namespace, module, etc&hellip;</li> </ul> Yet human centric way is absolutely different. We reference without location all the time. Yes we have search engines and they allow us to reference without location using natural language. More or less. And this is reason why <h2 id="graph-markup-language"> Graph Markup Language <a class="heading-link" href="#graph-markup-language"> Link to heading </a> </h2> was created and lays data in graphs instead of trees. This line of thinking proved it self very fruitful and as consequence of such a language came many innovative concepts which i termed ELM ELM - evolving language model is consequence of raising hierarchies from static to dynamic generalizing them and using them for dynamic language generation. Dynamically generated languages allow for ELM embodied in trinity of data &lt;-&gt; language &lt;-&gt; interaction What I&rsquo;m talking about is <ul> <li>deterministic</li> <li>interactive</li> <li>associative search</li> <li>with data space visualization</li> </ul> Laying data in graph in such a way that elevates even relation as first class citizen and allows for dynamic generation of languages arisen from data itself. This dynamic language is formal and keeps all the properties of formal languages <ul> <li>determinism.</li> </ul> To put it shortly expressions of GML define graphs, subgraphs which form mini brains capable of talking in multidimensional way about data. Read more in the book <h1 id="why-i-created-new-markup-language"> Why I created new markup language? <a class="heading-link" href="#why-i-created-new-markup-language"> Link to heading </a> </h1> Yet another time to call something &ldquo;yet another&rdquo; this time it is markup language. Yet another markup language&hellip; Why? <h2 id="current"> Current <a class="heading-link" href="#current"> Link to heading </a> </h2> HTML/XML is fair example. They are in essence as simple as it gets.  All that marking up was in days of early web to state what is what in mostly textual files and allow search engines to index it properly. Later on HTML became the most coupled tech in existence having some tags with semantic meaning, some with presentation meaning and some with both, then script tags and what not. This is because it was repurposed to follow the ever growing needs of web. The fact remains, You are marking up things and in process define trees. HTML is a tree of data. So is XML. So is JSON. While I went deeper into why and when trees are insufficient in the book, here Ill go briefly. HTML anticipated these insufficiencies and decided to bridge them with anchor tags. And that is - tree simply can&rsquo;t define as much as general graph can. So instead of defining coherent/atomic units of data, reference what you need. Those familiar with graphs will immediately recognize this leads to possibility of cycles. Cycles = problems and non determinism in many cases. Or simply &ldquo;oops this page can&rsquo;t be found&rdquo; To address the central lack of trees: laying data in trees is natural when we describe single taxonomy data is often viewed in multidimensional way and tree requires proclaiming one categorization as superior which is ambiguous and not self contained All this is the setup and something I named: <blockquote> core coupling of programming</blockquote> and that is we couple address/location with reference yet it is obviously coupling of two orthogonal concepts. As proof: <ul> <li>array index is memory location and reference</li> <li>url is location and reference literally</li> <li>file path is location and reference</li> <li>variable name is location and reference</li> <li>namespace, module, etc&hellip;</li> </ul> Yet human centric way is absolutely different. We reference without location all the time. Yes we have search engines and they allow us to reference without location using natural language. More or less. And this is reason why <h2 id="graph-markup-language"> Graph Markup Language <a class="heading-link" href="#graph-markup-language"> Link to heading </a> </h2> was created and lays data in graphs instead of trees. This line of thinking proved it self very fruitful and as consequence of such a language came many innovative concepts which i termed ELM ELM - evolving language model is consequence of raising hierarchies from static to dynamic generalizing them and using them for dynamic language generation. Dynamically generated languages allow for ELM embodied in trinity of data &lt;-&gt; language &lt;-&gt; interaction What I&rsquo;m talking about is <ul> <li>deterministic</li> <li>interactive</li> <li>associative search</li> <li>with data space visualization</li> </ul> Laying data in graph in such a way that elevates even relation as first class citizen and allows for dynamic generation of languages arisen from data itself. This dynamic language is formal and keeps all the properties of formal languages <ul> <li>determinism.</li> </ul> To put it shortly expressions of GML define graphs, subgraphs which form mini brains capable of talking in multidimensional way about data. Read more in the book Tradeoffs of Module Management https://316c0611.personalpage-ahl.pages.dev/posts/module-tradeoffs/ https://316c0611.personalpage-ahl.pages.dev/posts/module-tradeoffs/ Mon, 26 May 2025 11:20:59 +0200 <h1 id="tradeoffs-of-module-management"> Tradeoffs of Module Management <a class="heading-link" href="#tradeoffs-of-module-management"> Link to heading </a> </h1> We all want reusability—until we’re in a hurry. Or under-skilled. Or just trying to ship something today instead of tomorrow. Reusability takes extra thought, extra structure, and a level of patience most developers can’t afford in the moment. So what do we do instead? We reach for the batteries-included approach. npm install becomes our reflex. Install a library for everything—debounce, isEqual, date formatting. You end up with three different utilities solving the same problem… and use none of them. But hey, you get battle-tested code. Often feature-rich. Reusable. The cost? Bloat. And often, poor fit for your exact problem. So what’s the alternative? <h2 id="own-your-dependencies"> Own your dependencies. <a class="heading-link" href="#own-your-dependencies"> Link to heading </a> </h2> Write exactly what you need. Small, sharp modules tailored to your system. Minimal by design. Reusable on your terms. Sounds good, right? Until it becomes your job to maintain them. First you build. Then you reuse. Then you realize you need to patch. Then patch again. Now you need tests. Now you need a proper build pipeline. So you move to a monorepo to keep it manageable. Now you’re dealing with cascading changes, test orchestration, and CI complexity. Even then—monorepos don’t save you from versioning. If a module lives deep in your dependency tree, changing it isn’t cheap. You either keep it backward-compatible, or you bump the version and update every consumer. And now you’re back in cascading effort territory. <h2 id="heres-the-central-catch"> Here’s the central catch: <a class="heading-link" href="#heres-the-central-catch"> Link to heading </a> </h2> If you start owning your dependencies, they’ll often lack what you need. You’ll patch them. You’ll generalize them. You’ll try to reuse them across domains—and they won’t quite fit. That’s the moment most developers hit a wall. Do you make it generic? Do you fork? Do you duplicate? You’re back to versioning, rewrites, and the weight of ownership. <h2 id="so-which-path-do-you-choose"> So which path do you choose? <a class="heading-link" href="#so-which-path-do-you-choose"> Link to heading </a> </h2> Install and bloat — fast, reliable, but heavy and often misaligned. Write and own — light, tailored, but eventually expensive. Both are valid. And if you&rsquo;re building anything specific—anything real—you&rsquo;ll probably do both. The key isn’t picking one. The key is knowing where to draw the line. As we developers love to say: It’s an NP-hard problem. But even NP-hard problems can be tamed—with experience. <h1 id="tradeoffs-of-module-management"> Tradeoffs of Module Management <a class="heading-link" href="#tradeoffs-of-module-management"> Link to heading </a> </h1> We all want reusability—until we’re in a hurry. Or under-skilled. Or just trying to ship something today instead of tomorrow. Reusability takes extra thought, extra structure, and a level of patience most developers can’t afford in the moment. So what do we do instead? We reach for the batteries-included approach. npm install becomes our reflex. Install a library for everything—debounce, isEqual, date formatting. You end up with three different utilities solving the same problem… and use none of them. But hey, you get battle-tested code. Often feature-rich. Reusable. The cost? Bloat. And often, poor fit for your exact problem. So what’s the alternative? <h2 id="own-your-dependencies"> Own your dependencies. <a class="heading-link" href="#own-your-dependencies"> Link to heading </a> </h2> Write exactly what you need. Small, sharp modules tailored to your system. Minimal by design. Reusable on your terms. Sounds good, right? Until it becomes your job to maintain them. First you build. Then you reuse. Then you realize you need to patch. Then patch again. Now you need tests. Now you need a proper build pipeline. So you move to a monorepo to keep it manageable. Now you’re dealing with cascading changes, test orchestration, and CI complexity. Even then—monorepos don’t save you from versioning. If a module lives deep in your dependency tree, changing it isn’t cheap. You either keep it backward-compatible, or you bump the version and update every consumer. And now you’re back in cascading effort territory. <h2 id="heres-the-central-catch"> Here’s the central catch: <a class="heading-link" href="#heres-the-central-catch"> Link to heading </a> </h2> If you start owning your dependencies, they’ll often lack what you need. You’ll patch them. You’ll generalize them. You’ll try to reuse them across domains—and they won’t quite fit. That’s the moment most developers hit a wall. Do you make it generic? Do you fork? Do you duplicate? You’re back to versioning, rewrites, and the weight of ownership. <h2 id="so-which-path-do-you-choose"> So which path do you choose? <a class="heading-link" href="#so-which-path-do-you-choose"> Link to heading </a> </h2> Install and bloat — fast, reliable, but heavy and often misaligned. Write and own — light, tailored, but eventually expensive. Both are valid. And if you&rsquo;re building anything specific—anything real—you&rsquo;ll probably do both. The key isn’t picking one. The key is knowing where to draw the line. As we developers love to say: It’s an NP-hard problem. But even NP-hard problems can be tamed—with experience. 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. The missing development metric - UX complexity https://316c0611.personalpage-ahl.pages.dev/posts/uxmetrix/ https://316c0611.personalpage-ahl.pages.dev/posts/uxmetrix/ Sat, 17 May 2025 09:22:50 +0200 <h1 id="the-missing-development-metric---ux-complexity"> The missing development metric - UX complexity <a class="heading-link" href="#the-missing-development-metric---ux-complexity"> Link to heading </a> </h1> While everyone, ok not every one is talking about computational complexity. Especially in high level languages with accent to functional programming.Recomputation is the name of the game. So even on that old topic a lot could be said. But UX complexity - the cost of interaction as arguably the most important metric and its not yet a termed metric. Let&rsquo;s face it, if you nailed UX complexity, you nailed computational complexity long ago. <h2 id="innovation-in-ux-is-educational-process"> Innovation in UX is educational process <a class="heading-link" href="#innovation-in-ux-is-educational-process"> Link to heading </a> </h2> Yes we hear designers bragging about one click less UX experience. Yet they use standardized component libraries and expected UX patterns. Not much to invent, a lot to be careful about! It’s almost like innovative design is discouraged. And if you ever payed attention how people of age of higher number use their devices you start to realize educating people on UX principles is driven, multiple decades long education process. First they were inspired by the idea of free of cost calls, now they play candy crush 🍌. <h2 id="current-state-of-ux"> Current state of UX <a class="heading-link" href="#current-state-of-ux"> Link to heading </a> </h2> But if we step back even more, and see the UX of entire systems then clarity comes so easily. We do this to dig out problems and pain point I want to talk about. UX is <ul> <li>fragmented</li> <li>locking</li> </ul> Fragmented as UX is resembling more a corporate structure than intent of the user. Instead of sending a message being designed around UX of sending a message. It is designed around who owns the platform and what is the business model. There is nothing UX focused about that. Its all encompassing fragmentation of the system called &ldquo;app store&rdquo;. Current architecture is paas like. You have provider of platform - infrastructure (master). Then you have app fragmentation not caring a slightest bit about the user and intent. Then you have locking experiences in form of feeds, scrolls, hooks, notification pings and so on. <h3 id="on-ux"> O(n) UX <a class="heading-link" href="#on-ux"> Link to heading </a> </h3> Now scrolling is o(n) experience of UX where user is compelled to scroll like that pigeon with that button. 🔘🐦 And sadly, we all know how quickly time is traded in that trans like state. o(n) experience is unacceptable in any other areas as well. We all scrolled a gallery and after scrolling few hundred photos overscrolled past the photo like overlooking a food pot in fridge pointed by spouse. In one word, one emoji, trash 🗑️ <h3 id="olog-n-ux"> O(log n) UX <a class="heading-link" href="#olog-n-ux"> Link to heading </a> </h3> Menus are o(log n) and I must compel you they too are not good enough. They are obviously miles ahead of scrolling, but lets see how avoiding them will make your life easier. When I think menus I think - specialized software. Gimp, blender, and alike. Those kind of softwares still require specialized professional. Is that not all the proof we need? I mean, I can edit a photo but its like an elephant in glass store. To work effectively in that kind of software one must develop muscle memory. Productive work needs muscle memory. And this is more important then you think. There is subconscious aversion if time to express your self and time to think of what you want to express have too wide gap. Most accessible example is browsing on a slow connection. After 5 minutes you just don&rsquo;t want to do it. Its the exact same story when im trying to edit a photo. If i could just access the function (blur the damn photo)without clicking through menus and knowing particular specifics of the software, and developing muscle memory for all that, I too could edit a photo. Because in the end I know the result, I know what arguments to achieve it. The only thing preventing me is the UX. It might be seen as a skill issue, but it is not. It is a UX issue. Another example is scrolling through a file tree if you are a coder. Here I proclaim. <blockquote> Never scroll through a file tree. It makes you a coding monkey</blockquote> Disable that part of the IDE. It is a bad habit. A waste of time. You have so many more ways to access a location then scrolling through a file tree. It is disastrous degradation of log complexity into linear. And it is never worth scrolling and always better using something else. But on this topic I will write a separate log. <h3 id="o1-ux---the-dream"> O(1) UX - the dream <a class="heading-link" href="#o1-ux---the-dream"> Link to heading </a> </h3> So lets conclude this log entry by simply staying with the dream a while longer. <blockquote> We want to be able to command the system in any reach of our comprehension</blockquote> Now this is a dream envisioned in the movies and that iris episode of black mirror. AI chats kind of know what you want and they do provide wide range of solutions. We see more and more chat driven interfaces. But even that&hellip; response waits aint fun. So o(1) user experience complexity. I just think and the system knows what I want. What ever I want to refer to I can in constant time of user expression. Search engines kind of do this but you know: <ul> <li>marketing</li> <li>third party interests</li> <li>&hellip;</li> </ul> If you don&rsquo;t know what you are searching for, either by name or by link, you are screwed. Something is missing. Stick around for some of the next logs where I will explore this dream further. <h1 id="the-missing-development-metric---ux-complexity"> The missing development metric - UX complexity <a class="heading-link" href="#the-missing-development-metric---ux-complexity"> Link to heading </a> </h1> While everyone, ok not every one is talking about computational complexity. Especially in high level languages with accent to functional programming.Recomputation is the name of the game. So even on that old topic a lot could be said. But UX complexity - the cost of interaction as arguably the most important metric and its not yet a termed metric. Let&rsquo;s face it, if you nailed UX complexity, you nailed computational complexity long ago. <h2 id="innovation-in-ux-is-educational-process"> Innovation in UX is educational process <a class="heading-link" href="#innovation-in-ux-is-educational-process"> Link to heading </a> </h2> Yes we hear designers bragging about one click less UX experience. Yet they use standardized component libraries and expected UX patterns. Not much to invent, a lot to be careful about! It’s almost like innovative design is discouraged. And if you ever payed attention how people of age of higher number use their devices you start to realize educating people on UX principles is driven, multiple decades long education process. First they were inspired by the idea of free of cost calls, now they play candy crush 🍌. <h2 id="current-state-of-ux"> Current state of UX <a class="heading-link" href="#current-state-of-ux"> Link to heading </a> </h2> But if we step back even more, and see the UX of entire systems then clarity comes so easily. We do this to dig out problems and pain point I want to talk about. UX is <ul> <li>fragmented</li> <li>locking</li> </ul> Fragmented as UX is resembling more a corporate structure than intent of the user. Instead of sending a message being designed around UX of sending a message. It is designed around who owns the platform and what is the business model. There is nothing UX focused about that. Its all encompassing fragmentation of the system called &ldquo;app store&rdquo;. Current architecture is paas like. You have provider of platform - infrastructure (master). Then you have app fragmentation not caring a slightest bit about the user and intent. Then you have locking experiences in form of feeds, scrolls, hooks, notification pings and so on. <h3 id="on-ux"> O(n) UX <a class="heading-link" href="#on-ux"> Link to heading </a> </h3> Now scrolling is o(n) experience of UX where user is compelled to scroll like that pigeon with that button. 🔘🐦 And sadly, we all know how quickly time is traded in that trans like state. o(n) experience is unacceptable in any other areas as well. We all scrolled a gallery and after scrolling few hundred photos overscrolled past the photo like overlooking a food pot in fridge pointed by spouse. In one word, one emoji, trash 🗑️ <h3 id="olog-n-ux"> O(log n) UX <a class="heading-link" href="#olog-n-ux"> Link to heading </a> </h3> Menus are o(log n) and I must compel you they too are not good enough. They are obviously miles ahead of scrolling, but lets see how avoiding them will make your life easier. When I think menus I think - specialized software. Gimp, blender, and alike. Those kind of softwares still require specialized professional. Is that not all the proof we need? I mean, I can edit a photo but its like an elephant in glass store. To work effectively in that kind of software one must develop muscle memory. Productive work needs muscle memory. And this is more important then you think. There is subconscious aversion if time to express your self and time to think of what you want to express have too wide gap. Most accessible example is browsing on a slow connection. After 5 minutes you just don&rsquo;t want to do it. Its the exact same story when im trying to edit a photo. If i could just access the function (blur the damn photo)without clicking through menus and knowing particular specifics of the software, and developing muscle memory for all that, I too could edit a photo. Because in the end I know the result, I know what arguments to achieve it. The only thing preventing me is the UX. It might be seen as a skill issue, but it is not. It is a UX issue. Another example is scrolling through a file tree if you are a coder. Here I proclaim. <blockquote> Never scroll through a file tree. It makes you a coding monkey</blockquote> Disable that part of the IDE. It is a bad habit. A waste of time. You have so many more ways to access a location then scrolling through a file tree. It is disastrous degradation of log complexity into linear. And it is never worth scrolling and always better using something else. But on this topic I will write a separate log. <h3 id="o1-ux---the-dream"> O(1) UX - the dream <a class="heading-link" href="#o1-ux---the-dream"> Link to heading </a> </h3> So lets conclude this log entry by simply staying with the dream a while longer. <blockquote> We want to be able to command the system in any reach of our comprehension</blockquote> Now this is a dream envisioned in the movies and that iris episode of black mirror. AI chats kind of know what you want and they do provide wide range of solutions. We see more and more chat driven interfaces. But even that&hellip; response waits aint fun. So o(1) user experience complexity. I just think and the system knows what I want. What ever I want to refer to I can in constant time of user expression. Search engines kind of do this but you know: <ul> <li>marketing</li> <li>third party interests</li> <li>&hellip;</li> </ul> If you don&rsquo;t know what you are searching for, either by name or by link, you are screwed. Something is missing. Stick around for some of the next logs where I will explore this dream further. 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.