Late Architecture with Functional Programming
I think late architecture is orthogonal to functional, imperative and its solution is higher level than even functional programming and more abstract. I think the solution requires a new class of programming that is beyond APIs and functions. It&#x27;s the realm of relationships and pluralities, scheduling, understanding of meaning. (The realm of LLMs)<p>I want software architecture to be cheap and easy to change without breaking any existing behaviours. I don&#x27;t know much research on this subject.<p>I think APIs are the wrong thing to code against, because APIs are tied to architecture.<p>Some codebases are millions of lines big, it is extremely difficult to change a codebase&#x27;s architecture when it is that big. It&#x27;s either a lot of work or an extremely complicated program to rewrite sourcecode of that magnitude that isn&#x27;t throwaway and not general purpose transformations.<p>If you have a codebase that has a client per thread and you want to refactor it to multiplex clients over threads. Or you want to add load shedding or backpressure to your microservice architecture, you have a large amount of work to do. If you want to add a field to a message or underlying library that your every microservice architecture uses, you have a lot of pain to go through. If you want to change the workflow of a digitised business procedure you have a LOT of refactoring to do.<p>My ideas on the solution to this problem include:<p>- Vector programming: represent software architecture as vector embeddings, code against sequences of vectors that are arranged into relationships and then the space where the vectors reside is concretised<p>- Compositional behavioural typing: We need some way of combining behaviours together, composing the code of functions such that code is interleaved rather than chaining together functions. In most programming languages I know, data is typed, not the behaviour, and behaviour cannot be changed without changing the code. I think behaviour is more useful to type than data. Composing behaviour is not g(f(x)), it&#x27;s taking arbitrary parts of the innerworkings of f and g and applying behaviours to their mechanisms. Inheritance doesn&#x27;t do it properly, because you have to rewrite functions to replicate the original behaviour with a tweak. React hooks don&#x27;t do it. It&#x27;s the missing idea of computer science. My dream is that classes are compatible if you can provide a mapping from the innerworkings of one class to another class and the code can seamlessly compose without rewriting. And it be open to extension. It&#x27;s like metaprogramming for behaviour rather than types.<p>Code that that matches a &quot;dispatcher&quot; interface, automatically inferred by the compiler, and I can can insert a Load balancer or an ACL arbitrarily in the stack, anywhere.<p>I can change the plurality (one-to-many, many-to-one) of architectural relationships, such as insert a hierarchy of load balancers here between these objects. I can make my software internet scalable, multiregion, multithreaded by adding to the diagram. I can see the architecture as a giant relational diagram data structure and mutate it directly and cheaply and without breaking any existing behaviour.<p>I&#x27;ve been journalling about this on github.com&#x2F;samsquire&#x2F;ideas4<p>I also wrote <a href="https:&#x2F;&#x2F;devops-pipeline.com" rel="nofollow">https:&#x2F;&#x2F;devops-pipeline.com</a> which is an dataflow&#x2F;diagram based perspective of software infrastructure.