6 ms·

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

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...

mpweiher 5y ago
Hmm...interesting that you view this is a "rebuttal", as I generally regard it as further bolstering my point. I am certainly aware of it :-) First, I don't view Architecture Oriented Programming as being primarily about distributed programming, and so far my work at least has not been focused on it at all, though that is starting to change. Second, "everything would need to be rewritten in a single language" is not where I am going. At all. In fact, not requiring a single language is one of my central tenets, and particularly one of the reasons I reject Smalltalk-80, which very much wants everything to be in a single language in a single image. Third, "to support remote distribution, every procedure/interface/method would need to have full remote semantics". Nope, not at all. Only if you have a monomorphic view of language. The "Everything-is-a-"-ism. Also, almost all of these techniques went local-first, and then tried to add distribution. Which gives you the problem that remote semantics are not a trivial extension of local semantics. If you read the Note carefully, you will, er, note that it never talks about the reverse case, going from remote to local. For good reason, because the reverse case is fine. Which is one of the reasons In-Process REST works so well: it takes a distributed architecture and applies it (not 1:1, gotta adapt!) to the local case. Anyway, once you figure out that you can have polymorphism not just at the data-modelling layer, but also at the language meta-layer, you also start to understand that local/remote all-encompassing/not are false dichotomies. We have commonality and variability analysis, let's use it! These different mechanisms have some things in common, and others where they are different. If we open the language up sufficiently, we can capture both the commonalities and the differences in a way that is convenient and flexible. So when we get a new interaction mechanism, we write a new connector. Done. Going back to TFA and the John Hughes paper it quotes, the situation rightly critiqued in the Note is that of having one or maybe two "connectors" canonised into the language, one kind of glue. But as I write, we need lots, not one or two. So adding different kinds of connectors is the defining feature of Architecture Oriented Programming, and the exact opposite of the situation of baking one or maybe two into the language.
- abernard1 5y ago
  > But as I write, we need lots, not one or two. And those connectors need to be pushed down into the subsystems. This is the problem. Whatever the language used, you've effectively described a shared library, and one that needs to be handled by external cooperating services (including data stores). > For good reason, because the reverse case is fine. It is not, as per my above comment. Consistency requires bi-directional participation between actors if done at a uniform language or interface level, and good luck getting MySQL or Postgres to push your semantics into their software. For any HN users who are reading this and think "hey, writing everything in one language is totally fine!" please consider the first day you acquire a company / are looking to be acquired by another company that didn't use your language.

mpweiher 5y ago

Hmm...interesting that you view this is a "rebuttal", as I generally regard it as further bolstering my point. I am certainly aware of it :-) First, I don't view Architecture Oriented Programming as being primarily about distributed programming, and so far my work at least has not been focused on it at all, though that is starting to change. Second, "everything would need to be rewritten in a single language" is not where I am going. At all. In fact, not requiring a single language is one of my central tenets, and particularly one of the reasons I reject Smalltalk-80, which very much wants everything to be in a single language in a single image. Third, "to support remote distribution, every procedure/interface/method would need to have full remote semantics". Nope, not at all. Only if you have a monomorphic view of language. The "Everything-is-a-"-ism. Also, almost all of these techniques went local-first, and then tried to add distribution. Which gives you the problem that remote semantics are not a trivial extension of local semantics. If you read the Note carefully, you will, er, note that it never talks about the reverse case, going from remote to local. For good reason, because the reverse case is fine. Which is one of the reasons In-Process REST works so well: it takes a distributed architecture and applies it (not 1:1, gotta adapt!) to the local case. Anyway, once you figure out that you can have polymorphism not just at the data-modelling layer, but also at the language meta-layer, you also start to understand that local/remote all-encompassing/not are false dichotomies. We have commonality and variability analysis, let's use it! These different mechanisms have some things in common, and others where they are different. If we open the language up sufficiently, we can capture both the commonalities and the differences in a way that is convenient and flexible. So when we get a new interaction mechanism, we write a new connector. Done. Going back to TFA and the John Hughes paper it quotes, the situation rightly critiqued in the Note is that of having one or maybe two "connectors" canonised into the language, one kind of glue. But as I write, we need lots, not one or two. So adding different kinds of connectors is the defining feature of Architecture Oriented Programming, and the exact opposite of the situation of baking one or maybe two into the language.

abernard1 5y ago
> But as I write, we need lots, not one or two. And those connectors need to be pushed down into the subsystems. This is the problem. Whatever the language used, you've effectively described a shared library, and one that needs to be handled by external cooperating services (including data stores). > For good reason, because the reverse case is fine. It is not, as per my above comment. Consistency requires bi-directional participation between actors if done at a uniform language or interface level, and good luck getting MySQL or Postgres to push your semantics into their software. For any HN users who are reading this and think "hey, writing everything in one language is totally fine!" please consider the first day you acquire a company / are looking to be acquired by another company that didn't use your language.