It sounds like what you're suggesting is that we try to develop tools that look to an LLM to figure out which "functions" to call, and to write them if they don't already exist. In this way, a corpus of tokenized behaviors could be composited by an LLM to produce an on-the-fly program based in intent rather than syntax.
Is that a fair summary?
Yes you understand the thought! The thought isn't use ChatGPT to code existing programming languages but to take advantage of LLMs ability to traverse complicated relationships that result in logically composed behaviours.
A load balancer, access control list, pairwise zip, fork/join, map, reduce, interleaving, LIFO, FIFO, dispatcher, scheduling, binpacking, control loops, transformation, coordination, orchestration are all behaviours that could be useful in designing an architecture. An LLM probably knows the arguments they take and how to apply them to another scenario at an abstract level. They can match up the variables in each behaviour with what they map to.
For example, I don't need to write code that glues things together if the LLM knows where a load balancer should fit on a dispatcher
Today, that process is easier than ever but still very manual.
>I think late architecture is orthogonal to functional, imperative
Absolutely. From a truly architectural view, procedural, functional, and method-oriented (current OO) are really only variations on the call/return architectural style. Good and sometimes important distinctions, but not really that far apart. They are very much about computing, results from inputs. That is an appropriate architecture for fewer and fewer programs.
See Why Architecture Oriented Programming matters
https://blog.metaobject.com/2019/02/why-architecture-oriente...
and
Can Programmers Escape the Gentle Tyranny of call/return?
https://2020.programming-conference.org/details/salon-2020-p...
> its solution is higher level than even functional programming
Yes. Well, functional actually gets most of its utility from being lower level as far as paradigms go (less powerful). But yes.
> and more abstract
No. Well, yes, if expressed with current programming languages. But that's part of the problem set, not part of the solution set. We should be able to express our architectures less abstractly, more concretely, but for that we need linguistic support. Which is why I am working on that:
> 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.
There was quite a bit of research at CMU, for example on packaging mismatch. Famous paper Architectural Mismatch, Why Reuse is so hard, and the 10 year follow up in 2009: Architectural Mismatch: Why Reuse is Still So Hard
https://repository.upenn.edu/cgi/viewcontent.cgi?article=107...*
Not much has changed since.
> https://github.com/samsquire/ideas4
Will check those out. Dataflow is definitely a big part of it, with the extension of dataflow constraints (make, spreadsheets, "FRP"/"Rx"). But so is in-process REST with Storage Combinators!
And breaking down barriers between scripting and "real" programming.
Thank you for the links!
Sounds wonderful!
(What does it mean?)
I want to program my code that it can interoperate with many other pieces of software, without too much deliberate effort.
It means that the computer can work out how to wire one class with another class based on the desired behaviours of each class.
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.