3 ms·

The article leads to "Mary Shaw: Procedure Calls Are the Assembly Language of Software Interconnection: Connectors Deserve First-Class Status". Fixed link is h

by 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.
    - mpweiher 5y ago
      > I could see how the same language could be used for ADLs and programming I don't buy that there is an actually meaningful distinction between "ADL" and "programming". That's the point. Programming today is almost entirely composing existing procedures/functions/object/modules/libraries/programs in order to build a system. > but that implies programming all done in one language Why on earth would it imply that? It's not like there currently is only one "general purpose" language or just one "integration language". Objective-C is also a language that combines the integration mechanism ("Objective-") with the "programming" part ("C"). See Brad Cox's writing. But why have the integration mechanism be only messaging? Why not support others as well? And despite Objective-C combining these two aspects, there are other languages. And in fact, Objective-C is particularly good at talking to other languages. Objective-S is that, and also particularly good at talking to filters/pipelines (or being placed in a Unix pipe) and also particularly good at talking to REST servers via HTTP, and at creating modules that are accessed via HTTP by anyone. And at talking to filesystems and exporting components as FUSE servers. So I really don't get where this There Can Be Only One™ Uber-Language idea is coming from. It is the exact opposite of reality, at least in this case. > I can't think of a language that I'd want to use for everything. I can :-). For some specific definition of "everything". Once I get the native compiler fully working. > [hard part is] motivating everyone to use it. Motivating people to use stuff definitely is a hard part, but not sure why it has to be "everyone". But the way to get there is to identify a problem that is causing sufficient grief and provide a solution that is sufficiently compelling. I think I'm getting there. And then talk about it.

by jph 5y ago

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.
  - mpweiher 5y ago
    > I could see how the same language could be used for ADLs and programming I don't buy that there is an actually meaningful distinction between "ADL" and "programming". That's the point. Programming today is almost entirely composing existing procedures/functions/object/modules/libraries/programs in order to build a system. > but that implies programming all done in one language Why on earth would it imply that? It's not like there currently is only one "general purpose" language or just one "integration language". Objective-C is also a language that combines the integration mechanism ("Objective-") with the "programming" part ("C"). See Brad Cox's writing. But why have the integration mechanism be only messaging? Why not support others as well? And despite Objective-C combining these two aspects, there are other languages. And in fact, Objective-C is particularly good at talking to other languages. Objective-S is that, and also particularly good at talking to filters/pipelines (or being placed in a Unix pipe) and also particularly good at talking to REST servers via HTTP, and at creating modules that are accessed via HTTP by anyone. And at talking to filesystems and exporting components as FUSE servers. So I really don't get where this There Can Be Only One™ Uber-Language idea is coming from. It is the exact opposite of reality, at least in this case. > I can't think of a language that I'd want to use for everything. I can :-). For some specific definition of "everything". Once I get the native compiler fully working. > [hard part is] motivating everyone to use it. Motivating people to use stuff definitely is a hard part, but not sure why it has to be "everyone". But the way to get there is to identify a problem that is causing sufficient grief and provide a solution that is sufficiently compelling. I think I'm getting there. And then talk about it.