Why Architecture Oriented Programming Matters (2019)
I read the Shaw 1994 paper in full, and have a rebuttal paper that makes me confident the author&#x27;s goal of an architectural programming language will fail.<p>The paper is A Note on Distributed Computing (1994) [1], and a choice quote is:<p><pre><code>  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.

</code></pre>
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.<p>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&#x2F;interface&#x2F;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&#x27;s an API or a database, the whole thing breaks down.  Naive programmers using languages with message passing that say &quot;when you need to scale, you can just make that function remote&quot; find out very quickly that you cannot.<p>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 <i>actively</i>, that software is called an <i>orchestrator</i>, and it makes all the calls directly.  If systems are connected together <i>passively</i>, the subsystems themselves engage in <i>choreography</i>, and need to support a partial protocol of idempotency, awareness of ordering, retry semantics, etc.<p>[1] <a href="https:&#x2F;&#x2F;scholar.harvard.edu&#x2F;waldo&#x2F;publications&#x2F;note-distributed-computing" rel="nofollow">https:&#x2F;&#x2F;scholar.harvard.edu&#x2F;waldo&#x2F;publications&#x2F;note-distribu...</a>