3 ms·

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 v

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
  > you've effectively described a shared library You're creating a false dichotomy. Shared libraries are totally fine. > It is not, as per my above comment. Yes it is, as per my comment. > good luck getting MySQL or Postgres to push your semantics into their software. No luck needed as there is no such requirement. > "hey, writing everything in one language is totally fine!" Once again: you are completely making up this "everything in one language" bit out of nothing. There is no such requirement or even goal. Though once you find out how nice it is to program in that language, you might want to write everything with it.
Jupe 5y ago
> So when we get a new interaction mechanism, we write a new connector. Done. Interesting idea... but I'm struggling to get the full picture here... (I might be way-off here, but): Is this about "formalizing" connectors? Such that, once a connector technology comes along (RPC, REST, Web Sockets, GraphQL, who knows what next), such connectors could be implemented on either side of the boundary layers and then "selected" via some architectural language? I think the semantics of each "connector" demands different design constraints on either side of the equation. An overly simplified example: Java logging "appenders" allow dispatching log messages to different targets (stdout, filesystem, database, etc.) But, STDOUT doesn't "fill up", while file systems/databases do. DB's support querying, while STDOUT does not. DB's do get overwhelmed; should processing halt until such "overwhelmed" situations get resolved? Databases (should) include security; STDOUT does not. Etc. If there were different "types" of connectors defined, each with different behaviors, and those could be easily chosen, then maybe. But even the "types" would be solution-dependent. Retry rules, idempotency, serialization rules, compensating transaction support, etc. These topics (to me) are far more important than simply creating new connectors.
- abernard1 5y ago
  > These topics (to me) are far more important than simply creating new connectors. Yes. What this vision requires is pushing down a shared library or coordinated behavior into every new language or future technology that requires it. If the behavior is not actually required, and is more of a suggestion, then it's a "protocol" and requires interface modifications everywhere. And now we're back to "why do we need this shared code/language?" and "how is this different than patterns?" This model has been tried many many times. We just got rid of the ignominious stench of CORBA and its removal from Java in the last year after a 25 year failure. The architecture astronauts require their language to be guaranteed across wire boundaries which is a fancy way of saying that their uber-language needs to be implemented in all the subsystems for guarantees to work.
  - mpweiher 5y ago
    > What this vision requires is pushing down a shared library or coordinated behavior into every new language or future technology that requires it. NO IT DOES NOT. Please do not repeat this false claim. > This model has been tried many many times No. What YOU describe has been tried many times. It doesn't work. We agree. > The architecture astronauts require their language to be guaranteed across wire boundaries Yep. This does not. > which is a fancy way of saying that their uber-language needs to be implemented in all the subsystems for guarantees to work. Yep. Which is why that is a bad idea.
igouy 5y ago
> … Smalltalk-80, which very much wants everything to be in a single language in a single image. Except that Smalltalk implementations became a way to implement (and experiment with) other programming languages — "Metalinguistic Abstraction in Smalltalk-80 (or: Making Smalltalk with a Lisp)" https://www.researchgate.net/publication/2574069_Metalinguistic_Abstraction_in_Smalltalk-80_or_Making_Smalltalk_with_a_Lisp https://www.researchgate.net/publication/2574069_Metalinguis... "Why Smalltalk Wins the Host Languages Shootout" http://scg.unibe.ch/archive/papers/Reng09bLanguageShootout.pdf http://scg.unibe.ch/archive/papers/Reng09bLanguageShootout.p... "Squimera: A live, Smalltalk based IDE for dynamic programming languages" https://hpi.de/fileadmin/user_upload/hpi/dokumente/publikationen/technische_berichte/tbhpi120.pdf https://hpi.de/fileadmin/user_upload/hpi/dokumente/publikati...

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
> you've effectively described a shared library You're creating a false dichotomy. Shared libraries are totally fine. > It is not, as per my above comment. Yes it is, as per my comment. > good luck getting MySQL or Postgres to push your semantics into their software. No luck needed as there is no such requirement. > "hey, writing everything in one language is totally fine!" Once again: you are completely making up this "everything in one language" bit out of nothing. There is no such requirement or even goal. Though once you find out how nice it is to program in that language, you might want to write everything with it.

Jupe 5y ago

> So when we get a new interaction mechanism, we write a new connector. Done. Interesting idea... but I'm struggling to get the full picture here... (I might be way-off here, but): Is this about "formalizing" connectors? Such that, once a connector technology comes along (RPC, REST, Web Sockets, GraphQL, who knows what next), such connectors could be implemented on either side of the boundary layers and then "selected" via some architectural language? I think the semantics of each "connector" demands different design constraints on either side of the equation. An overly simplified example: Java logging "appenders" allow dispatching log messages to different targets (stdout, filesystem, database, etc.) But, STDOUT doesn't "fill up", while file systems/databases do. DB's support querying, while STDOUT does not. DB's do get overwhelmed; should processing halt until such "overwhelmed" situations get resolved? Databases (should) include security; STDOUT does not. Etc. If there were different "types" of connectors defined, each with different behaviors, and those could be easily chosen, then maybe. But even the "types" would be solution-dependent. Retry rules, idempotency, serialization rules, compensating transaction support, etc. These topics (to me) are far more important than simply creating new connectors.

abernard1 5y ago
> These topics (to me) are far more important than simply creating new connectors. Yes. What this vision requires is pushing down a shared library or coordinated behavior into every new language or future technology that requires it. If the behavior is not actually required, and is more of a suggestion, then it's a "protocol" and requires interface modifications everywhere. And now we're back to "why do we need this shared code/language?" and "how is this different than patterns?" This model has been tried many many times. We just got rid of the ignominious stench of CORBA and its removal from Java in the last year after a 25 year failure. The architecture astronauts require their language to be guaranteed across wire boundaries which is a fancy way of saying that their uber-language needs to be implemented in all the subsystems for guarantees to work.
- mpweiher 5y ago
  > What this vision requires is pushing down a shared library or coordinated behavior into every new language or future technology that requires it. NO IT DOES NOT. Please do not repeat this false claim. > This model has been tried many many times No. What YOU describe has been tried many times. It doesn't work. We agree. > The architecture astronauts require their language to be guaranteed across wire boundaries Yep. This does not. > which is a fancy way of saying that their uber-language needs to be implemented in all the subsystems for guarantees to work. Yep. Which is why that is a bad idea.

igouy 5y ago

> … Smalltalk-80, which very much wants everything to be in a single language in a single image. Except that Smalltalk implementations became a way to implement (and experiment with) other programming languages — "Metalinguistic Abstraction in Smalltalk-80 (or: Making Smalltalk with a Lisp)" https://www.researchgate.net/publication/2574069_Metalinguistic_Abstraction_in_Smalltalk-80_or_Making_Smalltalk_with_a_Lisp https://www.researchgate.net/publication/2574069_Metalinguis... "Why Smalltalk Wins the Host Languages Shootout" http://scg.unibe.ch/archive/papers/Reng09bLanguageShootout.pdf http://scg.unibe.ch/archive/papers/Reng09bLanguageShootout.p... "Squimera: A live, Smalltalk based IDE for dynamic programming languages" https://hpi.de/fileadmin/user_upload/hpi/dokumente/publikationen/technische_berichte/tbhpi120.pdf https://hpi.de/fileadmin/user_upload/hpi/dokumente/publikati...