4 ms·

I think late architecture is orthogonal to functional, imperative and its solution is higher level than even functional programming and more abstract. I think t

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 https://devops-pipeline.com which is an dataflow/diagram based perspective of software infrastructure.

dtagames 3y ago
I like where you're going with this. There is certainly room for improvement in programming in general, beyond just the new LLM applications that using existing programming paradigms. 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?
- samsquire 3y ago
  Thanks for your lovely comment. 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
  - dtagames 3y ago
    Indeed. On the front end side, there are many scaffolding steps required to even display a simple web page. Certainly all of those inner components and their functions could be subbed out with different appearance or different data using an LLM. Today, that process is easier than ever but still very manual.
mpweiher 3y ago
Great comment! >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-oriented-programming.html 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-papers/5/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: http://objective.st http://objective.st > 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=1074&context=library_papers https://repository.upenn.edu/cgi/viewcontent.cgi?article=107...* Not much has changed since. > https://github.com/samsquire/ideas4 https://github.com/samsquire/ideas4 > https://devops-pipeline.com https://devops-pipeline.com 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.

dtagames 3y ago

I like where you're going with this. There is certainly room for improvement in programming in general, beyond just the new LLM applications that using existing programming paradigms. 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?

samsquire 3y ago
Thanks for your lovely comment. 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
- dtagames 3y ago
  Indeed. On the front end side, there are many scaffolding steps required to even display a simple web page. Certainly all of those inner components and their functions could be subbed out with different appearance or different data using an LLM. Today, that process is easier than ever but still very manual.

mpweiher 3y ago

Great comment! >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-oriented-programming.html 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-papers/5/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: http://objective.st http://objective.st > 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=1074&context=library_papers https://repository.upenn.edu/cgi/viewcontent.cgi?article=107...* Not much has changed since. > https://github.com/samsquire/ideas4 https://github.com/samsquire/ideas4 > https://devops-pipeline.com https://devops-pipeline.com 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.