9 ms·

Why Architecture Oriented Programming Matters (2019)

86 points by mpweiher 5y ago

jph 5y ago
The article leads to "Mary Shaw: Procedure Calls Are the Assembly Language of Software Interconnection: Connectors Deserve First-Class Status". Fixed link is https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=12137 https://resources.sei.cmu.edu/library/asset-view.cfm?assetid... Abstract: Software designers compose systems from components written in some programming language. They regularly describe systems using abstract patterns and sophisticated relations among components. However, the configuration tools at their disposal restrict them to composition mechanisms directly supported by the programming language. To remedy this lack of expressiveness, we must elevate the relations among components to first-class entities of the system, entitled to their own specifications and abstractions.
- mpweiher 5y ago
  Thanks, fixed!
- karmakaze 5y ago
  This 1994 paper is the important bit rather than the 2019 post. What it describes isn't much different than the interfaces that we have in operating system loadable modules or application-ecosystems with plugins. The only distinction is the requirement of first-class status. This would require a unification of language, operating system, and application. The closest I've seen to something like that is NeXT with Objective-C and the NS framework/Kits. The evolution of that into macOS/iOS, Swift, and *Kits are less so. The other thing that comes to mind when reading this is the adage about any configuration file format evolving to become a poorly implemented subset of lisp. As long as software development is a commercial endeavor I don't see how we'd ever end up with full interoperability with the goals being counter to it.
  - mpweiher 5y ago
    > This 1994 paper is the important bit rather than the 2019 post Absolutely agreed, in terms of significance! But a slightly distinct point. > The only distinction is the requirement of first-class status. But an important distinction! We can currently build this. Which is good. But we cannot express it directly. This is bad, as this aspect is getting more and more important. > The closest I've seen to something like that is NeXT with Objective-C and the NS framework/Kits. Also 100% agreement! And probably not a coincidence that this is my "home". Also important: Brad Cox's book about Objective-C, which is very architectural and goes far beyond the language. And shows you what the language is trying to accomplish. Alas... > The evolution of that into macOS/iOS, Swift, and *Kits are less so. Exactly. :-( We seem to be moving backward instead of forward. > The other thing that comes to mind when reading this is the adage about any configuration file format evolving to become a poorly implemented subset of lisp. I think that's two adages: (1) all config file formats evolving into cobbled together programming languages and (2) any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. [1] This ties into one of the few points where I actually disagree with Mary Shaw, otherwise all I am doing is implementing her vision. Well, my feeble misinterpretation of her vision. Anyway, my disagreement is that I do not believe ADLs and programming languages are distinct, and I also believe that this belief that they are distinct is what's been preventing all this insight into software architecture from being as useful as it should be. Hence Objective-Smalltalk. (ArchJava was another foray, that had other problems, again IMHO). We'll see how it works out. [1] https://en.wikipedia.org/wiki/Greenspun's_tenth_rule https://en.wikipedia.org/wiki/Greenspun's_tenth_rule
    - karmakaze 5y ago
      I could see how the same language could be used for ADLs and programming, but that implies programming all done in one language which is the part I don't see happening. I don't even know that it's desirable. I can't think of a language that I'd want to use for everything. Being possible isn't even the hard part--it's motivating everyone to use it. The trend has been to own an aspect that is controlled by the first party and limit interoperability.
      - 5y ago
Zababa 5y ago
I've said a few times that modern microservice architectures feel a lot like what traditional object-oriented programming was about, and I think this is another confirmation of that. I think that these days the connectors are JSON over HTTP, RPC and things like that. When a service exposes a JSON over HTTP API, I can use it from any programming language, from any program. So "first class connectors", to me, would be something like a language describing how to interact with a service, and a code generator that takes that language and transform it into code in your language. For example, the aws-sdk-rust [1] says: > The SDK is code generated from Smithy models that represent each AWS service. The code used to generate the SDK can be found in smithy-rs. Here's a link to Smithy's homepage: https://awslabs.github.io/smithy/ https://awslabs.github.io/smithy/. To me, Smithy with a code generator looks like a connector that would increase your productivity. But I'm not sure if we can call something that relies on code generation "first class". I'm not sure what "first class connectors" would look like either. [1]: https://github.com/awslabs/aws-sdk-rust https://github.com/awslabs/aws-sdk-rust
- Jupe 5y ago
  Very cool - thanks for sharing; I'd not seen Smithy before (and was quite curious how AWS manages it "all"!) From the web page: > A Smithy model enables API providers to generate clients and servers in various programming languages, API documentation, test automation, and example code. Yes. This. Please.
abernard1 5y ago
I read the Shaw 1994 paper in full, and have a rebuttal paper that makes me confident the author's goal of an architectural programming language will fail. The paper is A Note on Distributed Computing (1994) [1], and a choice quote is: Historically, the language approach has been the less influential of the two camps. Every ten years (approximately), members of the language camp notice that the number of distributed applications is relatively small. They look at the programming interfaces and decide that the problem is that the programming model is not close enough to whatever programming model is currently in vogue (messages in the 1970s, procedure calls in the 1980s, and objects in the 1990s). A furious bout of language and protocol design takes place and a new distributed computing paradigm is announced that is compliant with the latest programming model. After several years, the percentage of distributed applications is discovered not to have increased significantly, and the cycle begins anew. Even in 1994, failures at achieving this dream were cliché. I will not resummarize the paper, but I will explain the crux of the problem with architectural languages. The problem with this dream is that to achieve it, (1) everything would need to be rewritten in a single language and (2) to support remote distribution, every procedure/interface/method would need to have full remote semantics. Many languages have tried this, including Smalltalk-sympathetic object message-passing languages like Erlang or Akka Actors. What you quickly realize when working with these languages is that the semantics of ordering, retries, idempotency, synchronization (all of the concepts that fit under the CAP theorem) are not easily expressed in a language. If you have anything remote whatsoever, whether that's an API or a database, the whole thing breaks down. Naive programmers using languages with message passing that say "when you need to scale, you can just make that function remote" find out very quickly that you cannot. The industry solution to this problem is one of interfaces and patterns, not all-encompassing languages. Use of an RPC or serialization data format (even heterogenous ones!) across subsystems provides transport glue, and another piece of software can provide semantics to make software work in concert together. If systems are connected together actively, that software is called an orchestrator, and it makes all the calls directly. If systems are connected together passively, the subsystems themselves engage in choreography, and need to support a partial protocol of idempotency, awareness of ordering, retry semantics, etc. [1] https://scholar.harvard.edu/waldo/publications/note-distributed-computing https://scholar.harvard.edu/waldo/publications/note-distribu...
chriswarbo 5y ago
Another thing to keep in mind is that the usefulness of "glue" depends on what it can stick. For example function composition is very useful in functional programming, precisely because (first-class) functions are used for so many things in FP. Relatedly, "composition" (of functions or anything else) is a powerful idea precisely because the result of a composition is the same kind of thing as the components; hence we can keep composing more and more.
Supermancho 5y ago
> Therefore, to increase one’s ability to modularize a problem conceptually, one must provide new kinds of glue in the programming language. > He just made the important point that "one must provide new kinds of glue" and then the amount of "new kinds of glue" is the smallest number that actually justifies using the plural. The real issue is the appeal to authority. John Huges didn't make a point; he made a claim. Specifically "new kinds of glue" is a troubling phrase, that has likely been misused more than just this blogpost. The statement implies there are more than was common at the time of writing (maybe?). It doesn't specifically mean there need be more than lambdas, closures, and mixins or more implementations of the same in different ways (runtime composition via aspects, copy-paste composition via traits, etc). I would think this needs more study, as it's more of a casual observation than a strong claim. Was Perl the most modular? Maybe so. I don't think that made it the most useful, implying an upper boundary, as Marcel noted.
- mpweiher 5y ago
  > The real issue is the appeal to authority. No appeal to authority here as I don't claim this as true, just interesting. > John Huges didn't make a point; he made a claim. Actually, he did make a point, as he provided reasoning for his claim. > The statement implies there are more than was common at the time of writing (maybe?) There are. Towards a Taxonomy of Software Connectors https://dl.acm.org/doi/10.1145/337180.337201 https://dl.acm.org/doi/10.1145/337180.337201 / https://csis.pace.edu/~marchese/CS865/Papers/p178-mehta.pdf https://csis.pace.edu/~marchese/CS865/Papers/p178-mehta.pdf I count > 100 leaf nodes in their classification tree. Not sure I agree with all of them, and there are probably others they missed. But more than 2 is trivially fulfilled. > Was Perl the most modular? Hmm...Perl wouldn't come to mind as something with a way for a user to define and refine new connectors.
  - Supermancho 5y ago
    > Perl wouldn't come to mind as something with a way for a user to define and refine new connectors. Anyone can add a new features to a language that users want to use. The source of the new connectors are incidental (user defined vs native syntax). That aside, operator overloading is fits the specific "user glue" you are focusing on. Perl added this in 1999. Perl pretty much had everything (Moose object system, etc).
GuestHNUser 5y ago
This blog reminds me of something John Carmack calls architecture astronauts. It talks about "glue" / connectors integrated with a programming language, which at a high level, sounds really nice. But I am skeptical of how well one could implement it in practice. Interoperating is far from standardized and I definitely want concrete examples illustrating what "Architecture Oriented" is in code and not theory. I hope there is a part two for this.
- mpweiher 5y ago
  Funny, I call it "architecture without the astronautics", because you get to express architecture in a very simple and straightforward manner. http://objective.st/ http://objective.st/ Sample scripts: https://github.com/mpw/Objective-Smalltalk/tree/master/scripts/ https://github.com/mpw/Objective-Smalltalk/tree/master/scrip...
  - xvedejas 5y ago
    > Objective-S is the first general purpose programming language. You should consider removing this claim, since it is a flat-out lie, or at least a willful disregard for the language that other people use. If you want to communicate what is novel about this programming language, you need to remove this. It heavily detracts from the architectural mechanisms that you start to explain on the "About" page (http://objective.st/About http://objective.st/About) which seems to be the actual meat, where you could flesh out further explanation.
    - mpweiher 5y ago
      It's not a lie, though it obviously is controversial. The languages we call "general purpose" are nothing of the sort. They are Domain Specific Languages for the domain of algorithms. We press them into service for all sorts of things they aren't actually very good at, hence the problems. We do so because we don't have any alternatives. Took me a long time to figure this out. And an much longer time to communicate it concisely. So yes, I can deal with it not being immediately obvious.

86 points by mpweiher 5y ago

jph 5y ago

The article leads to "Mary Shaw: Procedure Calls Are the Assembly Language of Software Interconnection: Connectors Deserve First-Class Status". Fixed link is https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=12137 https://resources.sei.cmu.edu/library/asset-view.cfm?assetid... Abstract: Software designers compose systems from components written in some programming language. They regularly describe systems using abstract patterns and sophisticated relations among components. However, the configuration tools at their disposal restrict them to composition mechanisms directly supported by the programming language. To remedy this lack of expressiveness, we must elevate the relations among components to first-class entities of the system, entitled to their own specifications and abstractions.

mpweiher 5y ago
Thanks, fixed!
karmakaze 5y ago
This 1994 paper is the important bit rather than the 2019 post. What it describes isn't much different than the interfaces that we have in operating system loadable modules or application-ecosystems with plugins. The only distinction is the requirement of first-class status. This would require a unification of language, operating system, and application. The closest I've seen to something like that is NeXT with Objective-C and the NS framework/Kits. The evolution of that into macOS/iOS, Swift, and *Kits are less so. The other thing that comes to mind when reading this is the adage about any configuration file format evolving to become a poorly implemented subset of lisp. As long as software development is a commercial endeavor I don't see how we'd ever end up with full interoperability with the goals being counter to it.
- mpweiher 5y ago
  > This 1994 paper is the important bit rather than the 2019 post Absolutely agreed, in terms of significance! But a slightly distinct point. > The only distinction is the requirement of first-class status. But an important distinction! We can currently build this. Which is good. But we cannot express it directly. This is bad, as this aspect is getting more and more important. > The closest I've seen to something like that is NeXT with Objective-C and the NS framework/Kits. Also 100% agreement! And probably not a coincidence that this is my "home". Also important: Brad Cox's book about Objective-C, which is very architectural and goes far beyond the language. And shows you what the language is trying to accomplish. Alas... > The evolution of that into macOS/iOS, Swift, and *Kits are less so. Exactly. :-( We seem to be moving backward instead of forward. > The other thing that comes to mind when reading this is the adage about any configuration file format evolving to become a poorly implemented subset of lisp. I think that's two adages: (1) all config file formats evolving into cobbled together programming languages and (2) any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. [1] This ties into one of the few points where I actually disagree with Mary Shaw, otherwise all I am doing is implementing her vision. Well, my feeble misinterpretation of her vision. Anyway, my disagreement is that I do not believe ADLs and programming languages are distinct, and I also believe that this belief that they are distinct is what's been preventing all this insight into software architecture from being as useful as it should be. Hence Objective-Smalltalk. (ArchJava was another foray, that had other problems, again IMHO). We'll see how it works out. [1] https://en.wikipedia.org/wiki/Greenspun's_tenth_rule https://en.wikipedia.org/wiki/Greenspun's_tenth_rule
  - karmakaze 5y ago
    I could see how the same language could be used for ADLs and programming, but that implies programming all done in one language which is the part I don't see happening. I don't even know that it's desirable. I can't think of a language that I'd want to use for everything. Being possible isn't even the hard part--it's motivating everyone to use it. The trend has been to own an aspect that is controlled by the first party and limit interoperability.
    - 5y ago

Zababa 5y ago

I've said a few times that modern microservice architectures feel a lot like what traditional object-oriented programming was about, and I think this is another confirmation of that. I think that these days the connectors are JSON over HTTP, RPC and things like that. When a service exposes a JSON over HTTP API, I can use it from any programming language, from any program. So "first class connectors", to me, would be something like a language describing how to interact with a service, and a code generator that takes that language and transform it into code in your language. For example, the aws-sdk-rust [1] says: > The SDK is code generated from Smithy models that represent each AWS service. The code used to generate the SDK can be found in smithy-rs. Here's a link to Smithy's homepage: https://awslabs.github.io/smithy/ https://awslabs.github.io/smithy/. To me, Smithy with a code generator looks like a connector that would increase your productivity. But I'm not sure if we can call something that relies on code generation "first class". I'm not sure what "first class connectors" would look like either. [1]: https://github.com/awslabs/aws-sdk-rust https://github.com/awslabs/aws-sdk-rust

Jupe 5y ago
Very cool - thanks for sharing; I'd not seen Smithy before (and was quite curious how AWS manages it "all"!) From the web page: > A Smithy model enables API providers to generate clients and servers in various programming languages, API documentation, test automation, and example code. Yes. This. Please.

abernard1 5y ago

I read the Shaw 1994 paper in full, and have a rebuttal paper that makes me confident the author's goal of an architectural programming language will fail. The paper is A Note on Distributed Computing (1994) [1], and a choice quote is: Historically, the language approach has been the less influential of the two camps. Every ten years (approximately), members of the language camp notice that the number of distributed applications is relatively small. They look at the programming interfaces and decide that the problem is that the programming model is not close enough to whatever programming model is currently in vogue (messages in the 1970s, procedure calls in the 1980s, and objects in the 1990s). A furious bout of language and protocol design takes place and a new distributed computing paradigm is announced that is compliant with the latest programming model. After several years, the percentage of distributed applications is discovered not to have increased significantly, and the cycle begins anew. Even in 1994, failures at achieving this dream were cliché. I will not resummarize the paper, but I will explain the crux of the problem with architectural languages. The problem with this dream is that to achieve it, (1) everything would need to be rewritten in a single language and (2) to support remote distribution, every procedure/interface/method would need to have full remote semantics. Many languages have tried this, including Smalltalk-sympathetic object message-passing languages like Erlang or Akka Actors. What you quickly realize when working with these languages is that the semantics of ordering, retries, idempotency, synchronization (all of the concepts that fit under the CAP theorem) are not easily expressed in a language. If you have anything remote whatsoever, whether that's an API or a database, the whole thing breaks down. Naive programmers using languages with message passing that say "when you need to scale, you can just make that function remote" find out very quickly that you cannot. The industry solution to this problem is one of interfaces and patterns, not all-encompassing languages. Use of an RPC or serialization data format (even heterogenous ones!) across subsystems provides transport glue, and another piece of software can provide semantics to make software work in concert together. If systems are connected together actively, that software is called an orchestrator, and it makes all the calls directly. If systems are connected together passively, the subsystems themselves engage in choreography, and need to support a partial protocol of idempotency, awareness of ordering, retry semantics, etc. [1] https://scholar.harvard.edu/waldo/publications/note-distributed-computing https://scholar.harvard.edu/waldo/publications/note-distribu...

chriswarbo 5y ago

Another thing to keep in mind is that the usefulness of "glue" depends on what it can stick. For example function composition is very useful in functional programming, precisely because (first-class) functions are used for so many things in FP. Relatedly, "composition" (of functions or anything else) is a powerful idea precisely because the result of a composition is the same kind of thing as the components; hence we can keep composing more and more.

Supermancho 5y ago

> Therefore, to increase one’s ability to modularize a problem conceptually, one must provide new kinds of glue in the programming language. > He just made the important point that "one must provide new kinds of glue" and then the amount of "new kinds of glue" is the smallest number that actually justifies using the plural. The real issue is the appeal to authority. John Huges didn't make a point; he made a claim. Specifically "new kinds of glue" is a troubling phrase, that has likely been misused more than just this blogpost. The statement implies there are more than was common at the time of writing (maybe?). It doesn't specifically mean there need be more than lambdas, closures, and mixins or more implementations of the same in different ways (runtime composition via aspects, copy-paste composition via traits, etc). I would think this needs more study, as it's more of a casual observation than a strong claim. Was Perl the most modular? Maybe so. I don't think that made it the most useful, implying an upper boundary, as Marcel noted.

mpweiher 5y ago
> The real issue is the appeal to authority. No appeal to authority here as I don't claim this as true, just interesting. > John Huges didn't make a point; he made a claim. Actually, he did make a point, as he provided reasoning for his claim. > The statement implies there are more than was common at the time of writing (maybe?) There are. Towards a Taxonomy of Software Connectors https://dl.acm.org/doi/10.1145/337180.337201 https://dl.acm.org/doi/10.1145/337180.337201 / https://csis.pace.edu/~marchese/CS865/Papers/p178-mehta.pdf https://csis.pace.edu/~marchese/CS865/Papers/p178-mehta.pdf I count > 100 leaf nodes in their classification tree. Not sure I agree with all of them, and there are probably others they missed. But more than 2 is trivially fulfilled. > Was Perl the most modular? Hmm...Perl wouldn't come to mind as something with a way for a user to define and refine new connectors.
- Supermancho 5y ago
  > Perl wouldn't come to mind as something with a way for a user to define and refine new connectors. Anyone can add a new features to a language that users want to use. The source of the new connectors are incidental (user defined vs native syntax). That aside, operator overloading is fits the specific "user glue" you are focusing on. Perl added this in 1999. Perl pretty much had everything (Moose object system, etc).

GuestHNUser 5y ago

This blog reminds me of something John Carmack calls architecture astronauts. It talks about "glue" / connectors integrated with a programming language, which at a high level, sounds really nice. But I am skeptical of how well one could implement it in practice. Interoperating is far from standardized and I definitely want concrete examples illustrating what "Architecture Oriented" is in code and not theory. I hope there is a part two for this.

mpweiher 5y ago
Funny, I call it "architecture without the astronautics", because you get to express architecture in a very simple and straightforward manner. http://objective.st/ http://objective.st/ Sample scripts: https://github.com/mpw/Objective-Smalltalk/tree/master/scripts/ https://github.com/mpw/Objective-Smalltalk/tree/master/scrip...
- xvedejas 5y ago
  > Objective-S is the first general purpose programming language. You should consider removing this claim, since it is a flat-out lie, or at least a willful disregard for the language that other people use. If you want to communicate what is novel about this programming language, you need to remove this. It heavily detracts from the architectural mechanisms that you start to explain on the "About" page (http://objective.st/About http://objective.st/About) which seems to be the actual meat, where you could flesh out further explanation.
  - mpweiher 5y ago
    It's not a lie, though it obviously is controversial. The languages we call "general purpose" are nothing of the sort. They are Domain Specific Languages for the domain of algorithms. We press them into service for all sorts of things they aren't actually very good at, hence the problems. We do so because we don't have any alternatives. Took me a long time to figure this out. And an much longer time to communicate it concisely. So yes, I can deal with it not being immediately obvious.