Innovation · djuleayo

Innovation · djuleayo https://316c0611.personalpage-ahl.pages.dev/tags/innovation/ Hugo en Dynamically Generated Languages vs MCP Servers https://316c0611.personalpage-ahl.pages.dev/posts/dynamical-languages/ https://316c0611.personalpage-ahl.pages.dev/posts/dynamical-languages/ Sun, 18 Jan 2026 17:10:43 +0200 <h1 id="dynamically-generated-languages-solve-the-same-class-of-problems-as-mcp-servers--and-do-it-better"> Dynamically Generated Languages Solve the Same Class of Problems as MCP Servers — and Do It Better <a class="heading-link" href="#dynamically-generated-languages-solve-the-same-class-of-problems-as-mcp-servers--and-do-it-better"> Link to heading </a> </h1> After battle-testing these ideas in practice, here is my conclusion: Centralized interaction and intent architectures are inevitable. The only real question is whether we build them as formal systems or probabilistic agents. <hr> <h2 id="from-clicking-and-scrolling-to-invoking-capabilities"> From Clicking and Scrolling to Invoking Capabilities <a class="heading-link" href="#from-clicking-and-scrolling-to-invoking-capabilities"> Link to heading </a> </h2> User interaction is moving away from clicking and scrolling and toward invoking capabilities directly, most notably via voice. This shift is powerful: <ul> <li>If you can name a capability, you can invoke it</li> <li>Interaction becomes direct</li> <li>UX complexity drops dramatically</li> </ul> From a UX-complexity standpoint, this is a clear win. However, this change forces a fundamental architectural shift compared to traditional frontend setups. <hr> <h2 id="react-and-the-problem-of-distributed-capabilities"> React and the Problem of Distributed Capabilities <a class="heading-link" href="#react-and-the-problem-of-distributed-capabilities"> Link to heading </a> </h2> Consider a typical React application. In React: <ul> <li>Capabilities are exposed through components</li> <li>Components expose behavior via props and callbacks</li> <li>Capabilities are therefore distributed by construction</li> </ul> There is no centralized place where “what the system can do” exists. Trying to centralize this in React quickly reveals deep friction: <ul> <li>Hooks produce unstable references across renders</li> <li>Central registries must constantly re-register handlers</li> <li>Context-based solutions become brittle and stateful</li> <li>Unsubscribing DOM listeners requires the exact same function reference</li> <li>That reference is often no longer available or stable</li> </ul> Yes, you can build a capability registry on top of React. But it is: <ul> <li>Clunky</li> <li>Hard to reason about</li> <li>Tightly coupled to rendering lifecycle</li> <li>Architecturally inverted</li> </ul> All of this is a strong signal: centralized capability invocation does not belong inside the UI layer. <hr> <h2 id="centralization-is-not-optional"> Centralization Is Not Optional <a class="heading-link" href="#centralization-is-not-optional"> Link to heading </a> </h2> Now compare this with a system like the Visual Studio Code command palette. VS Code exposes: <ul> <li>A centralized</li> <li>Runtime-configurable</li> <li>Discoverable</li> <li>Uniform command surface</li> </ul> Once a command is registered: <ul> <li>It does not matter where it lives</li> <li>It does not matter which UI triggered it</li> <li>It can be invoked uniformly</li> </ul> This is not an accident. It is a capability-first architecture. <hr> <h2 id="the-natural-conclusion-a-decoupled-capability-layer"> The Natural Conclusion: A Decoupled Capability Layer <a class="heading-link" href="#the-natural-conclusion-a-decoupled-capability-layer"> Link to heading </a> </h2> What naturally follows is a module that: <ul> <li>Is decoupled from the frontend</li> <li>Has no dependency on UI frameworks</li> <li>Accepts voice or textual input</li> <li>Emits discrete, authorized commands</li> </ul> At first glance, this smells like parsing. And that is exactly what it is — with one important caveat. <hr> <h2 id="this-is-parsing--not-ai"> This Is Parsing — Not AI <a class="heading-link" href="#this-is-parsing--not-ai"> Link to heading </a> </h2> Traditional parsing assumes: <ul> <li>Full input available upfront</li> <li>A lexing phase</li> <li>A parsing phase</li> <li>A final AST</li> </ul> User interaction does not work this way. For voice and interactive input we need: <ul> <li>Incremental parsing</li> <li>Partial feedback</li> <li>Real-time guidance</li> <li>Asynchronous evaluation</li> </ul> This is not AI. This is asynchronous parsing. That distinction matters. <hr> <h2 id="mcp-servers-and-the-core-problem"> MCP Servers and the Core Problem <a class="heading-link" href="#mcp-servers-and-the-core-problem"> Link to heading </a> </h2> MCP servers attempt to solve a similar problem: <ul> <li>Centralized capability invocation</li> <li>Access via natural language</li> <li>Location-agnostic execution</li> </ul> In practice: <ul> <li>Once a capability is integrated, its origin no longer matters</li> <li>If you can name it, you can invoke it</li> </ul> On the surface, this sounds ideal. It is not. <hr> <h2 id="why-informal-invocation-is-dangerous"> Why Informal Invocation Is Dangerous <a class="heading-link" href="#why-informal-invocation-is-dangerous"> Link to heading </a> </h2> MCP-style systems rely on: <ul> <li>NLP → mapping informal language to formal side effects</li> <li>Agents → which can and do hallucinate</li> </ul> This creates a fundamental mismatch: <ul> <li>Informal input</li> <li>Formal consequences</li> </ul> The moment real side effects exist, you must introduce: <ul> <li>Authorization</li> <li>Capability scoping</li> <li>Denial rules</li> <li>Auditability</li> </ul> At that point, you are already rebuilding a formal system. <hr> <h2 id="languages-are-formal-systems"> Languages Are Formal Systems <a class="heading-link" href="#languages-are-formal-systems"> Link to heading </a> </h2> Languages: <ul> <li>Are minimal</li> <li>Are precise</li> <li>Can be syntactically close to natural language</li> <li>Support deterministic navigation</li> <li>Enable runtime introspection (autocomplete, discovery)</li> </ul> Most importantly: Languages allow relational identification. Objects are identified not by name alone, but by their position in a capability topology. This is strictly stronger than nominal invocation. <hr> <h2 id="relational-navigation-beats-nominal-invocation"> Relational Navigation Beats Nominal Invocation <a class="heading-link" href="#relational-navigation-beats-nominal-invocation"> Link to heading </a> </h2> LLMs are good at resolving names. They are bad at: <ul> <li>Systematic search</li> <li>Relational exploration</li> <li>Topological disambiguation</li> </ul> A formal language enables: <ul> <li>Search through capability graphs</li> <li>Context-aware narrowing</li> <li>Progressive discovery</li> <li>Authorization by construction</li> </ul> This is not “autocomplete”. This is relational observation over a formal structure. <hr> <h2 id="the-implementation-is-already-known"> The Implementation Is Already Known <a class="heading-link" href="#the-implementation-is-already-known"> Link to heading </a> </h2> Asynchronous parsing is not new. Generators: <ul> <li>Exist in JavaScript for over a decade</li> <li>Are foundational in operating systems</li> <li>Are widely used in parsers and schedulers</li> </ul> They are exactly the right abstraction: <ul> <li>Incremental</li> <li>Stateful</li> <li>Deterministic</li> <li>Interruptible</li> </ul> Nothing exotic is required. <hr> <h2 id="the-critical-difference"> The Critical Difference <a class="heading-link" href="#the-critical-difference"> Link to heading </a> </h2> The most important outcome of such a system is this: It can correctly deny you access. This places it in a completely different category than LLM-driven systems. LLMs aim to be helpful. Formal systems aim to be correct. When invoking real capabilities, correctness wins. <hr> <h2 id="closing"> Closing <a class="heading-link" href="#closing"> Link to heading </a> </h2> Dynamically generated languages and centralized capability graphs solve the same class of problems as MCP servers. They do so: <ul> <li>Deterministically</li> <li>Safely</li> <li>Transparently</li> <li>With better UX</li> <li>And with lower long-term complexity</li> </ul> This is not the future of “AI interfaces”. This is the future of intent architecture. <h1 id="dynamically-generated-languages-solve-the-same-class-of-problems-as-mcp-servers--and-do-it-better"> Dynamically Generated Languages Solve the Same Class of Problems as MCP Servers — and Do It Better <a class="heading-link" href="#dynamically-generated-languages-solve-the-same-class-of-problems-as-mcp-servers--and-do-it-better"> Link to heading </a> </h1> After battle-testing these ideas in practice, here is my conclusion: Centralized interaction and intent architectures are inevitable. The only real question is whether we build them as formal systems or probabilistic agents. <hr> <h2 id="from-clicking-and-scrolling-to-invoking-capabilities"> From Clicking and Scrolling to Invoking Capabilities <a class="heading-link" href="#from-clicking-and-scrolling-to-invoking-capabilities"> Link to heading </a> </h2> User interaction is moving away from clicking and scrolling and toward invoking capabilities directly, most notably via voice. This shift is powerful: <ul> <li>If you can name a capability, you can invoke it</li> <li>Interaction becomes direct</li> <li>UX complexity drops dramatically</li> </ul> From a UX-complexity standpoint, this is a clear win. However, this change forces a fundamental architectural shift compared to traditional frontend setups. <hr> <h2 id="react-and-the-problem-of-distributed-capabilities"> React and the Problem of Distributed Capabilities <a class="heading-link" href="#react-and-the-problem-of-distributed-capabilities"> Link to heading </a> </h2> Consider a typical React application. In React: <ul> <li>Capabilities are exposed through components</li> <li>Components expose behavior via props and callbacks</li> <li>Capabilities are therefore distributed by construction</li> </ul> There is no centralized place where “what the system can do” exists. Trying to centralize this in React quickly reveals deep friction: <ul> <li>Hooks produce unstable references across renders</li> <li>Central registries must constantly re-register handlers</li> <li>Context-based solutions become brittle and stateful</li> <li>Unsubscribing DOM listeners requires the exact same function reference</li> <li>That reference is often no longer available or stable</li> </ul> Yes, you can build a capability registry on top of React. But it is: <ul> <li>Clunky</li> <li>Hard to reason about</li> <li>Tightly coupled to rendering lifecycle</li> <li>Architecturally inverted</li> </ul> All of this is a strong signal: centralized capability invocation does not belong inside the UI layer. <hr> <h2 id="centralization-is-not-optional"> Centralization Is Not Optional <a class="heading-link" href="#centralization-is-not-optional"> Link to heading </a> </h2> Now compare this with a system like the Visual Studio Code command palette. VS Code exposes: <ul> <li>A centralized</li> <li>Runtime-configurable</li> <li>Discoverable</li> <li>Uniform command surface</li> </ul> Once a command is registered: <ul> <li>It does not matter where it lives</li> <li>It does not matter which UI triggered it</li> <li>It can be invoked uniformly</li> </ul> This is not an accident. It is a capability-first architecture. <hr> <h2 id="the-natural-conclusion-a-decoupled-capability-layer"> The Natural Conclusion: A Decoupled Capability Layer <a class="heading-link" href="#the-natural-conclusion-a-decoupled-capability-layer"> Link to heading </a> </h2> What naturally follows is a module that: <ul> <li>Is decoupled from the frontend</li> <li>Has no dependency on UI frameworks</li> <li>Accepts voice or textual input</li> <li>Emits discrete, authorized commands</li> </ul> At first glance, this smells like parsing. And that is exactly what it is — with one important caveat. <hr> <h2 id="this-is-parsing--not-ai"> This Is Parsing — Not AI <a class="heading-link" href="#this-is-parsing--not-ai"> Link to heading </a> </h2> Traditional parsing assumes: <ul> <li>Full input available upfront</li> <li>A lexing phase</li> <li>A parsing phase</li> <li>A final AST</li> </ul> User interaction does not work this way. For voice and interactive input we need: <ul> <li>Incremental parsing</li> <li>Partial feedback</li> <li>Real-time guidance</li> <li>Asynchronous evaluation</li> </ul> This is not AI. This is asynchronous parsing. That distinction matters. <hr> <h2 id="mcp-servers-and-the-core-problem"> MCP Servers and the Core Problem <a class="heading-link" href="#mcp-servers-and-the-core-problem"> Link to heading </a> </h2> MCP servers attempt to solve a similar problem: <ul> <li>Centralized capability invocation</li> <li>Access via natural language</li> <li>Location-agnostic execution</li> </ul> In practice: <ul> <li>Once a capability is integrated, its origin no longer matters</li> <li>If you can name it, you can invoke it</li> </ul> On the surface, this sounds ideal. It is not. <hr> <h2 id="why-informal-invocation-is-dangerous"> Why Informal Invocation Is Dangerous <a class="heading-link" href="#why-informal-invocation-is-dangerous"> Link to heading </a> </h2> MCP-style systems rely on: <ul> <li>NLP → mapping informal language to formal side effects</li> <li>Agents → which can and do hallucinate</li> </ul> This creates a fundamental mismatch: <ul> <li>Informal input</li> <li>Formal consequences</li> </ul> The moment real side effects exist, you must introduce: <ul> <li>Authorization</li> <li>Capability scoping</li> <li>Denial rules</li> <li>Auditability</li> </ul> At that point, you are already rebuilding a formal system. <hr> <h2 id="languages-are-formal-systems"> Languages Are Formal Systems <a class="heading-link" href="#languages-are-formal-systems"> Link to heading </a> </h2> Languages: <ul> <li>Are minimal</li> <li>Are precise</li> <li>Can be syntactically close to natural language</li> <li>Support deterministic navigation</li> <li>Enable runtime introspection (autocomplete, discovery)</li> </ul> Most importantly: Languages allow relational identification. Objects are identified not by name alone, but by their position in a capability topology. This is strictly stronger than nominal invocation. <hr> <h2 id="relational-navigation-beats-nominal-invocation"> Relational Navigation Beats Nominal Invocation <a class="heading-link" href="#relational-navigation-beats-nominal-invocation"> Link to heading </a> </h2> LLMs are good at resolving names. They are bad at: <ul> <li>Systematic search</li> <li>Relational exploration</li> <li>Topological disambiguation</li> </ul> A formal language enables: <ul> <li>Search through capability graphs</li> <li>Context-aware narrowing</li> <li>Progressive discovery</li> <li>Authorization by construction</li> </ul> This is not “autocomplete”. This is relational observation over a formal structure. <hr> <h2 id="the-implementation-is-already-known"> The Implementation Is Already Known <a class="heading-link" href="#the-implementation-is-already-known"> Link to heading </a> </h2> Asynchronous parsing is not new. Generators: <ul> <li>Exist in JavaScript for over a decade</li> <li>Are foundational in operating systems</li> <li>Are widely used in parsers and schedulers</li> </ul> They are exactly the right abstraction: <ul> <li>Incremental</li> <li>Stateful</li> <li>Deterministic</li> <li>Interruptible</li> </ul> Nothing exotic is required. <hr> <h2 id="the-critical-difference"> The Critical Difference <a class="heading-link" href="#the-critical-difference"> Link to heading </a> </h2> The most important outcome of such a system is this: It can correctly deny you access. This places it in a completely different category than LLM-driven systems. LLMs aim to be helpful. Formal systems aim to be correct. When invoking real capabilities, correctness wins. <hr> <h2 id="closing"> Closing <a class="heading-link" href="#closing"> Link to heading </a> </h2> Dynamically generated languages and centralized capability graphs solve the same class of problems as MCP servers. They do so: <ul> <li>Deterministically</li> <li>Safely</li> <li>Transparently</li> <li>With better UX</li> <li>And with lower long-term complexity</li> </ul> This is not the future of “AI interfaces”. This is the future of intent architecture. 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 Language agnostic steno theory https://316c0611.personalpage-ahl.pages.dev/posts/lang-agnostic-steno/ https://316c0611.personalpage-ahl.pages.dev/posts/lang-agnostic-steno/ Sat, 31 May 2025 14:31:18 +0200 What a glorious weekend. What a joy. In two days I implemented <blockquote> language agnostic steno theory</blockquote> There is code at the bottom but lets focus on the theory first. <h2 id="my-take-on-why-steno-is-appealing"> My take on why steno is appealing <a class="heading-link" href="#my-take-on-why-steno-is-appealing"> Link to heading </a> </h2> 200 wpm non invasive hmi. Full words: 200 words per minute without a chip and usb port in your head interface for commanding a machine. Basically thought speed interface. Appealing. As short as that! A chip in your heard has r/w and idea of w in my head already creeps me out even without a chip so no thank you. So demanding muscle memory training it is. <h2 id="theory-is-why-existing-suck"> Theory is? Why existing suck <a class="heading-link" href="#theory-is-why-existing-suck"> Link to heading </a> </h2> There are multiple theories. And learning them is a pain. Theory is basically how you map chords to words. <ul> <li>steno is optimized for english</li> <li>they take years to learn</li> <li>That effort is wasted if it can’t generalize to other languages. (now it can, so those of you who wanted this, welcome home)</li> </ul> So learning it and having results in just one language is disaster. And as if language agnostic steno theory is not enough to hype, this theory is so much superior in theory metrix compared to existing its simply a question why it wasn&rsquo;t like this from the beginning. But step by step. Let&rsquo;s first see what are characteristics of a theory <h2 id="theory-characteristics"> Theory characteristics <a class="heading-link" href="#theory-characteristics"> Link to heading </a> </h2> <ul> <li>is it free of cost</li> <li>chords per word metric</li> <li>consistency</li> <li>memorization</li> </ul> Since there are billions of chords you need a system. Now the more you stay inside single system the more is consistent and easier to remember but staying in a system without exceptions leads to suboptimal solutions from time to time. So a theory trades consistency for less chords per word and with that requires more memorization. And showing this in practice existing theories exactly manifest these tradeoffs. And still whatever you choose you&rsquo;ll need to memorize thousands (literally) of entries, besides muscle memory, to be effective. <blockquote> Before completing this read you will learn entire new theory with better chord per word frequency then existing theories and with perfect consistency</blockquote> <h2 id="requirements"> Requirements <a class="heading-link" href="#requirements"> Link to heading </a> </h2> Sounds too good to be true, as as it is often a case with things that sound too good, there is a catch. So what is it? Let&rsquo;s not postpone the hit. You must know IPA - international phonetic alphabet. Not all of it 30 bloody letters covers most languages with almost 1 to 1 correspondence. Thats it. And some hardware requirements. Nothing else. Now I&rsquo;m going to be offensive, and intentionally so. Non phonetic writing languages <ul> <li>french</li> <li>english</li> <li>etc</li> </ul> This writing is broken. Yes it shows the history of word and its origin from a different language, ok, but writing should be defined and correlated to, well reading my dear friends. If this idea alone is too much for your molded brain to grasp get out of my sight. Now I get it, English is kind of dominant and dominance doesn&rsquo;t play nice. It is the one saying my way or the high way. But with trade off as this one? Again: Language agnostic maximally consistent, fastest theory you can forgo your stupid writing ways. I hope so And still, even existing theories go into IPA, so nothing new, just go all the way for that language agnostic truth. And Germans, Russians, sanskrit indian languages and clearly pure glory of south slav language aligned with IPA 100% will be at home with almost no gap. <h2 id="new-theory---design"> New theory - Design <a class="heading-link" href="#new-theory---design"> Link to heading </a> </h2> <h3 id="existing-hardware-analysis"> Existing hardware analysis <a class="heading-link" href="#existing-hardware-analysis"> Link to heading </a> </h3> When I started investigating steno, 200 wpm hmi glowed in intersection of my subconscious and conscious mind as Sun itself. But me being European, speaking 3 natural languages and many formal ones, fact of such gigantic effort being useless in ANY area of my machine interaction was out of question. So I didn&rsquo;t learn any existing theory. I invented new one. What I did 1st? Investigated existing hardware. Last decade was kind of giving in sense of ergonomic programmable keyboards opening entire new market to gracefully sink money overflows of coding monkeys. And it was devastating likewise, because bloody piece of plastic and &ldquo;whatever switch&rdquo; shouldn&rsquo;t be $500. Where the f is this world going. Anyhow&hellip; Diversity of hardware is nice, and i do enjoy it for long array of years now. I will cover truth of keyboard ergonomics on its own, but for now lets just say the core principle of ergonomics that defines the input hardware itself. <h3 id="ergonomics"> Ergonomics <a class="heading-link" href="#ergonomics"> Link to heading </a> </h3> Independence of movement. So those so called 3d switches can move any direction but if you spend some time watching your hand move you will notice there is no total independence of movement between fingers. To keep things short your index, thumb and pinky can move independently, both x and y axis meaning you can cover 4 buttons with each, but middle and ring finger are not independent on x axis only on y axis. Its simply hard to extend index and pinky and contract middle and ring at the same time. So to sum up, 4 bits for 3 fingers and 2 bits for 2 fingers. Ah yes, thumb explanation. Thumb clusters are example of overpriced engineering shame. Stamp it as ergonomic and set that high price, meanwhile it takes a decade for manufacturers to figure out what a good thumb cluster is. Just as i said it. Shame. Anyhow that radial thumb cluster is good, and it should have 3 or 4 buttons. As easy as that. Since we need bits give us 4 please. Thank you. <img src="https://www.zsa.io/cdn-cgi/image/width=769,quality=80,format=auto/@moonlander/images/legacy/22-blink-beep-0.webp" alt=""> Moonlander thumb cluster - approved ✅ Assuming button marked as arrow right is pressed with thumb also and far right button is far and ignored. <img src="https://cdn.shopify.com/s/files/1/0374/9448/9228/files/dygma-defy-showcase-compress.jpg?v=1678183523" alt=""> While defy is not optimal to hit those 8 buttons individually with thumb, pairs are wonderful. approved ✅ <img src="https://kyrremann.no/keebs/assets/images/elephant42.png" alt=""> Even something cheaper like this &ldquo;elephant&rdquo; baby works well. approved ✅ In some of following posts I will explain why you may need more then 42 buttons so it may lack in that regard, but thats another story. Now lets proceed. So far we have 16 bits for one hand. pinky 4 and ring 2, thats 6 Now wait a minute. Can you press diagonals with pinky, or 3 button combinations? Maybe, but we will not use those. So this reduces our bandwidth. Pinky has 8 realistic positions, 4 independent buttons, 2 verticals and 2 horizontals <h3 id="result"> Result <a class="heading-link" href="#result"> Link to heading </a> </h3> 8 * 4 = 32 positions for 2 fingers. We can map all letters there! IPA letters not trash joker letters like y. Sometimes reads this way, other times other way. Spare me. So here, example mapping. Straight into the gold mine: <pre tabindex="0"><code>` : `: , : ,: t k d c // : means ring finger does nothing ` ` `` , ` ,` v b f p ` , `, , , ,, r m n s ` | `| , | ,| l k dz z // | means vertical pressed --: __: | : |: j ch dj cj --` __` | ` |` a e i o --, __, | , |, h sh nj sj --| __| | | || u zh lj </code></pre>There is a thing of building new letters by attaching j (ipa j) or h on them. english: <ul> <li>c + h,</li> <li>z + h (like french jolie)</li> <li>s + h (ie show)</li> <li>n + j (new)</li> </ul> non english examples: d + j, t + j, l + j, s + j This concrete mapping is kind of easy to remember as it takes into account how letters are built by appending j or h, so s + h is same bits as s and vertical above, and similar for others. Modified letter is adjacent to the original Also, vowels are dense, often requiring 3 bits. This is because you are not supposed to type them in this manner. You will understand soon. If pinky and ring can type any letter, so do index and middle finger in exact same way just reflected in the mirror! So any 2 letters with 4 fingers. So far so good. Now thumb with 4 bits, not fully independent as not every combination can be pressed can cover 7 positions, 4 individual bits and 3 pairs. Sadly 5 vowels so 2 are useless. Not full bit remains. So pack vowels there. <h3 id="palm-bits"> Palm bits <a class="heading-link" href="#palm-bits"> Link to heading </a> </h3> Back to hardware. Model1 io is a nice board. It has that palm button. That is good Even on moonlander i use palm to press corner button of the board instead of pinky. Palm is independent from fingers too! 2 Independent bits! <img src="https://shop.keyboard.io/cdn/shop/files/m100-for-web.jpg?v=1706306369&amp;width=360" alt=""> Just imagine that palm button on outer side as well. Those I built alone using a cheap membrane keyboard monkey patching some cherries 🍒 on top. Can drop a guide if needed. For now this bit as all the guide you need. <img src="http://109.92.26.132/pic/palmButtons.gif" alt=""> Now obviously I didn&rsquo;t ducktape that thing on and with little cable management redistribute start record buttons across my home. Not at all. Twist hand inward a bit, or outward. Now we are up to 18! We will use those as vowel positioning bits. <ul> <li>Left hand outer palm = vowel left</li> <li>left hand inner palm = vowel right</li> </ul> And this allows us to make any 2 consonant 1 vowel trio. With one hand. Same but mirrored with other hand. That is any 6 letter 4 consonant 2 vowel combination. Most of the time there are not 3 consonants adjacent and even if there are we can process our input further without mandating memorization. <h3 id="independence-bit"> Independence bit <a class="heading-link" href="#independence-bit"> Link to heading </a> </h3> Last piece. If you press both palm positions this is chord independence flag. Meaning that chord is taken as word. Meaning you can type two short words at once Meaning chord frequency is awesome. So what i promised I delivered. No memorization (beyond 30 letters and muscle memory) no language locking, as input is taken as ipa and then mapped to a word however it is spelled (i don&rsquo;t really care &ldquo;oui je veux&rdquo; looking at you ) IPA required, hardware required. <pre tabindex="0"><code>` : |` .,,. ,,.. || ` ` </code></pre>is a chord notation and lets not go into whats mapped onto it. If you are interested decipher it using the map above :) Guides for hardware coming soon <h2 id="tease"> Tease <a class="heading-link" href="#tease"> Link to heading </a> </h2> Now that I just dropped this on you, trust me when I tell you. Typing is currently least of bottleneck for thought speed HMI. As I described here in <a href="http://www.djuleayo.com/posts/uxmetrix" class="external-link" target="_blank" rel="noopener">UX metrix</a>. But I have solution for that too! It is much more exiting then lang agnostic steno as it enables you so much further. True R.A.H.M.I random access human machine interface. Stay tuned. <h2 id="code"> Code <a class="heading-link" href="#code"> Link to heading </a> </h2> As promised here is the code. Its a small js driver basically that runs on linux but porting it to windows or mac should be really straightforward. Do note if you decide to run it how beautiful low level event driven JS in fact is. Such a treat after framework land. <a href="https://github.com/djuleAyo/lang-agnostic-steno" class="external-link" target="_blank" rel="noopener">GitHub repo</a> Don&rsquo;t forget to install dependencies outside of npm (xdotool) <h2 id="whats-missing"> Whats missing <a class="heading-link" href="#whats-missing"> Link to heading </a> </h2> Translating IPA into spellings layer is not there. I need to pull IPA data from somewhere. This is a POC and requires tweaking. <h2 id="meta-bracelet"> Meta bracelet <a class="heading-link" href="#meta-bracelet"> Link to heading </a> </h2> I expect this kind of steno could be fully ported to <a href="https://www.meta.com/en-gb/blog/surface-emg-wrist-white-paper-reality-labs/?srsltid=AfmBOoq1PwhcfmmWF1M3D995oefoVIIK-Sdb89sAWqKBbYif6zKmOIgc" class="external-link" target="_blank" rel="noopener">meta input bracelet</a> as each button press is distinct muscle movement. So even in that manner this training shouldn&rsquo;t go wasted. What a glorious weekend. What a joy. In two days I implemented <blockquote> language agnostic steno theory</blockquote> There is code at the bottom but lets focus on the theory first. <h2 id="my-take-on-why-steno-is-appealing"> My take on why steno is appealing <a class="heading-link" href="#my-take-on-why-steno-is-appealing"> Link to heading </a> </h2> 200 wpm non invasive hmi. Full words: 200 words per minute without a chip and usb port in your head interface for commanding a machine. Basically thought speed interface. Appealing. As short as that! A chip in your heard has r/w and idea of w in my head already creeps me out even without a chip so no thank you. So demanding muscle memory training it is. <h2 id="theory-is-why-existing-suck"> Theory is? Why existing suck <a class="heading-link" href="#theory-is-why-existing-suck"> Link to heading </a> </h2> There are multiple theories. And learning them is a pain. Theory is basically how you map chords to words. <ul> <li>steno is optimized for english</li> <li>they take years to learn</li> <li>That effort is wasted if it can’t generalize to other languages. (now it can, so those of you who wanted this, welcome home)</li> </ul> So learning it and having results in just one language is disaster. And as if language agnostic steno theory is not enough to hype, this theory is so much superior in theory metrix compared to existing its simply a question why it wasn&rsquo;t like this from the beginning. But step by step. Let&rsquo;s first see what are characteristics of a theory <h2 id="theory-characteristics"> Theory characteristics <a class="heading-link" href="#theory-characteristics"> Link to heading </a> </h2> <ul> <li>is it free of cost</li> <li>chords per word metric</li> <li>consistency</li> <li>memorization</li> </ul> Since there are billions of chords you need a system. Now the more you stay inside single system the more is consistent and easier to remember but staying in a system without exceptions leads to suboptimal solutions from time to time. So a theory trades consistency for less chords per word and with that requires more memorization. And showing this in practice existing theories exactly manifest these tradeoffs. And still whatever you choose you&rsquo;ll need to memorize thousands (literally) of entries, besides muscle memory, to be effective. <blockquote> Before completing this read you will learn entire new theory with better chord per word frequency then existing theories and with perfect consistency</blockquote> <h2 id="requirements"> Requirements <a class="heading-link" href="#requirements"> Link to heading </a> </h2> Sounds too good to be true, as as it is often a case with things that sound too good, there is a catch. So what is it? Let&rsquo;s not postpone the hit. You must know IPA - international phonetic alphabet. Not all of it 30 bloody letters covers most languages with almost 1 to 1 correspondence. Thats it. And some hardware requirements. Nothing else. Now I&rsquo;m going to be offensive, and intentionally so. Non phonetic writing languages <ul> <li>french</li> <li>english</li> <li>etc</li> </ul> This writing is broken. Yes it shows the history of word and its origin from a different language, ok, but writing should be defined and correlated to, well reading my dear friends. If this idea alone is too much for your molded brain to grasp get out of my sight. Now I get it, English is kind of dominant and dominance doesn&rsquo;t play nice. It is the one saying my way or the high way. But with trade off as this one? Again: Language agnostic maximally consistent, fastest theory you can forgo your stupid writing ways. I hope so And still, even existing theories go into IPA, so nothing new, just go all the way for that language agnostic truth. And Germans, Russians, sanskrit indian languages and clearly pure glory of south slav language aligned with IPA 100% will be at home with almost no gap. <h2 id="new-theory---design"> New theory - Design <a class="heading-link" href="#new-theory---design"> Link to heading </a> </h2> <h3 id="existing-hardware-analysis"> Existing hardware analysis <a class="heading-link" href="#existing-hardware-analysis"> Link to heading </a> </h3> When I started investigating steno, 200 wpm hmi glowed in intersection of my subconscious and conscious mind as Sun itself. But me being European, speaking 3 natural languages and many formal ones, fact of such gigantic effort being useless in ANY area of my machine interaction was out of question. So I didn&rsquo;t learn any existing theory. I invented new one. What I did 1st? Investigated existing hardware. Last decade was kind of giving in sense of ergonomic programmable keyboards opening entire new market to gracefully sink money overflows of coding monkeys. And it was devastating likewise, because bloody piece of plastic and &ldquo;whatever switch&rdquo; shouldn&rsquo;t be $500. Where the f is this world going. Anyhow&hellip; Diversity of hardware is nice, and i do enjoy it for long array of years now. I will cover truth of keyboard ergonomics on its own, but for now lets just say the core principle of ergonomics that defines the input hardware itself. <h3 id="ergonomics"> Ergonomics <a class="heading-link" href="#ergonomics"> Link to heading </a> </h3> Independence of movement. So those so called 3d switches can move any direction but if you spend some time watching your hand move you will notice there is no total independence of movement between fingers. To keep things short your index, thumb and pinky can move independently, both x and y axis meaning you can cover 4 buttons with each, but middle and ring finger are not independent on x axis only on y axis. Its simply hard to extend index and pinky and contract middle and ring at the same time. So to sum up, 4 bits for 3 fingers and 2 bits for 2 fingers. Ah yes, thumb explanation. Thumb clusters are example of overpriced engineering shame. Stamp it as ergonomic and set that high price, meanwhile it takes a decade for manufacturers to figure out what a good thumb cluster is. Just as i said it. Shame. Anyhow that radial thumb cluster is good, and it should have 3 or 4 buttons. As easy as that. Since we need bits give us 4 please. Thank you. <img src="https://www.zsa.io/cdn-cgi/image/width=769,quality=80,format=auto/@moonlander/images/legacy/22-blink-beep-0.webp" alt=""> Moonlander thumb cluster - approved ✅ Assuming button marked as arrow right is pressed with thumb also and far right button is far and ignored. <img src="https://cdn.shopify.com/s/files/1/0374/9448/9228/files/dygma-defy-showcase-compress.jpg?v=1678183523" alt=""> While defy is not optimal to hit those 8 buttons individually with thumb, pairs are wonderful. approved ✅ <img src="https://kyrremann.no/keebs/assets/images/elephant42.png" alt=""> Even something cheaper like this &ldquo;elephant&rdquo; baby works well. approved ✅ In some of following posts I will explain why you may need more then 42 buttons so it may lack in that regard, but thats another story. Now lets proceed. So far we have 16 bits for one hand. pinky 4 and ring 2, thats 6 Now wait a minute. Can you press diagonals with pinky, or 3 button combinations? Maybe, but we will not use those. So this reduces our bandwidth. Pinky has 8 realistic positions, 4 independent buttons, 2 verticals and 2 horizontals <h3 id="result"> Result <a class="heading-link" href="#result"> Link to heading </a> </h3> 8 * 4 = 32 positions for 2 fingers. We can map all letters there! IPA letters not trash joker letters like y. Sometimes reads this way, other times other way. Spare me. So here, example mapping. Straight into the gold mine: <pre tabindex="0"><code>` : `: , : ,: t k d c // : means ring finger does nothing ` ` `` , ` ,` v b f p ` , `, , , ,, r m n s ` | `| , | ,| l k dz z // | means vertical pressed --: __: | : |: j ch dj cj --` __` | ` |` a e i o --, __, | , |, h sh nj sj --| __| | | || u zh lj </code></pre>There is a thing of building new letters by attaching j (ipa j) or h on them. english: <ul> <li>c + h,</li> <li>z + h (like french jolie)</li> <li>s + h (ie show)</li> <li>n + j (new)</li> </ul> non english examples: d + j, t + j, l + j, s + j This concrete mapping is kind of easy to remember as it takes into account how letters are built by appending j or h, so s + h is same bits as s and vertical above, and similar for others. Modified letter is adjacent to the original Also, vowels are dense, often requiring 3 bits. This is because you are not supposed to type them in this manner. You will understand soon. If pinky and ring can type any letter, so do index and middle finger in exact same way just reflected in the mirror! So any 2 letters with 4 fingers. So far so good. Now thumb with 4 bits, not fully independent as not every combination can be pressed can cover 7 positions, 4 individual bits and 3 pairs. Sadly 5 vowels so 2 are useless. Not full bit remains. So pack vowels there. <h3 id="palm-bits"> Palm bits <a class="heading-link" href="#palm-bits"> Link to heading </a> </h3> Back to hardware. Model1 io is a nice board. It has that palm button. That is good Even on moonlander i use palm to press corner button of the board instead of pinky. Palm is independent from fingers too! 2 Independent bits! <img src="https://shop.keyboard.io/cdn/shop/files/m100-for-web.jpg?v=1706306369&amp;width=360" alt=""> Just imagine that palm button on outer side as well. Those I built alone using a cheap membrane keyboard monkey patching some cherries 🍒 on top. Can drop a guide if needed. For now this bit as all the guide you need. <img src="http://109.92.26.132/pic/palmButtons.gif" alt=""> Now obviously I didn&rsquo;t ducktape that thing on and with little cable management redistribute start record buttons across my home. Not at all. Twist hand inward a bit, or outward. Now we are up to 18! We will use those as vowel positioning bits. <ul> <li>Left hand outer palm = vowel left</li> <li>left hand inner palm = vowel right</li> </ul> And this allows us to make any 2 consonant 1 vowel trio. With one hand. Same but mirrored with other hand. That is any 6 letter 4 consonant 2 vowel combination. Most of the time there are not 3 consonants adjacent and even if there are we can process our input further without mandating memorization. <h3 id="independence-bit"> Independence bit <a class="heading-link" href="#independence-bit"> Link to heading </a> </h3> Last piece. If you press both palm positions this is chord independence flag. Meaning that chord is taken as word. Meaning you can type two short words at once Meaning chord frequency is awesome. So what i promised I delivered. No memorization (beyond 30 letters and muscle memory) no language locking, as input is taken as ipa and then mapped to a word however it is spelled (i don&rsquo;t really care &ldquo;oui je veux&rdquo; looking at you ) IPA required, hardware required. <pre tabindex="0"><code>` : |` .,,. ,,.. || ` ` </code></pre>is a chord notation and lets not go into whats mapped onto it. If you are interested decipher it using the map above :) Guides for hardware coming soon <h2 id="tease"> Tease <a class="heading-link" href="#tease"> Link to heading </a> </h2> Now that I just dropped this on you, trust me when I tell you. Typing is currently least of bottleneck for thought speed HMI. As I described here in <a href="http://www.djuleayo.com/posts/uxmetrix" class="external-link" target="_blank" rel="noopener">UX metrix</a>. But I have solution for that too! It is much more exiting then lang agnostic steno as it enables you so much further. True R.A.H.M.I random access human machine interface. Stay tuned. <h2 id="code"> Code <a class="heading-link" href="#code"> Link to heading </a> </h2> As promised here is the code. Its a small js driver basically that runs on linux but porting it to windows or mac should be really straightforward. Do note if you decide to run it how beautiful low level event driven JS in fact is. Such a treat after framework land. <a href="https://github.com/djuleAyo/lang-agnostic-steno" class="external-link" target="_blank" rel="noopener">GitHub repo</a> Don&rsquo;t forget to install dependencies outside of npm (xdotool) <h2 id="whats-missing"> Whats missing <a class="heading-link" href="#whats-missing"> Link to heading </a> </h2> Translating IPA into spellings layer is not there. I need to pull IPA data from somewhere. This is a POC and requires tweaking. <h2 id="meta-bracelet"> Meta bracelet <a class="heading-link" href="#meta-bracelet"> Link to heading </a> </h2> I expect this kind of steno could be fully ported to <a href="https://www.meta.com/en-gb/blog/surface-emg-wrist-white-paper-reality-labs/?srsltid=AfmBOoq1PwhcfmmWF1M3D995oefoVIIK-Sdb89sAWqKBbYif6zKmOIgc" class="external-link" target="_blank" rel="noopener">meta input bracelet</a> as each button press is distinct muscle movement. So even in that manner this training shouldn&rsquo;t go wasted. 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.