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's the realm of relationships and pluralities, scheduling, understanding of meaning. (The realm of LLMs)

I want software architecture to be cheap and easy to change without breaking any existing behaviours. I don't know much research on this subject.

I think APIs are the wrong thing to code against, because APIs are tied to architecture.

Some codebases are millions of lines big, it is extremely difficult to change a codebase's architecture when it is that big. It's either a lot of work or an extremely complicated program to rewrite sourcecode of that magnitude that isn't throwaway and not general purpose transformations.

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.

My ideas on the solution to this problem include:

- 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

- 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's taking arbitrary parts of the innerworkings of f and g and applying behaviours to their mechanisms. Inheritance doesn't do it properly, because you have to rewrite functions to replicate the original behaviour with a tweak. React hooks don't do it. It'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's like metaprogramming for behaviour rather than types.

Code that that matches a "dispatcher" interface, automatically inferred by the compiler, and I can can insert a Load balancer or an ACL arbitrarily in the stack, anywhere.

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.

I've been journalling about this on github.com/samsquire/ideas4

I also wrote https://devops-pipeline.com which is an dataflow/diagram based perspective of software infrastructure.