3 ms·

It is particularly sad that many languages treat foreign function interfaces and remote procedure calls as unwanted, debilitated children. I can easily imagine

It is particularly sad that many languages treat foreign function interfaces and remote procedure calls as unwanted, debilitated children. I can easily imagine a utopia in which software would plug together via function/procedure/method calls rather than shared files or web APIs or some other popular but improvised and less thought out alternatives. Why are we not there?

mpweiher 8y ago
> utopia in which software would plug together via function/procedure/method calls Hmm...The Fine Article actually argues that procedure calls are too low level for software interconnection, and that is the major reason why we aren't there. (and they haven't really improved in the last quarter century since the article was written). Like the analogy in the title of using assembly language to build large-scale software systems. But you're right that the alternatives are also often quite messy; talking to other systems is generally not considered a first class concern, but rather something you cobble together, somehow, out of parts that aren't necessarily fit for purpose. And I think there are actually good reasons for using web and file APIs (composability, simple GET/PUT semantics) that are independent of other aspects (using HTTP, OS mediation...) but come together in one package. My Objective-Smalltalk[1] is an attempt to build a language where these concerns are first class and separated out, for example with Polymorphic Identifiers[2] to generalise resource/variable access, Constraint Connectors[3] and Object Filters to generalise dataflow and Higher Order Messaging[4] to generalise messaging/procedure calls. One interesting outcome is that once you see these more general concepts in a "pure" setting, you can bring them back to other languages, for examples "Stores"[5]. Not quite as nice as with proper language support, but still very useful. [1] http://objective.st http://objective.st [2] https://dl.acm.org/citation.cfm?id=2508168.2508169 https://dl.acm.org/citation.cfm?id=2508168.2508169 https://www.hpi.uni-potsdam.de/hirschfeld/publications/media/WeiherHirschfeld_2013_PolymorphicIdentifiersUniformResourceAccessInObjectiveSmalltalk_AcmDL.pdf [3] https://dl.acm.org/citation.cfm?id=2889456 https://dl.acm.org/citation.cfm?id=2889456 https://www.hpi.uni-potsdam.de/hirschfeld/publications/media/WeiherHirschfeld_2016_ConstraintsAsPolymorphicConnectors_AuthorsVersion.pdf [4] https://en.wikipedia.org/wiki/Higher_order_message https://en.wikipedia.org/wiki/Higher_order_message [5] https://github.com/mpw/MPWFoundation/blob/master/Documentation/Stores.md https://github.com/mpw/MPWFoundation/blob/master/Documentati...
pubby 8y ago
Type systems, exception handlers, garbage collectors, allocators, etc from different languages are rarely compatible with each other.
- mpweiher 8y ago
  Yeah, another reason why we like to user serialised representations to talk to each other.
abernard1 8y ago
This thought has been around for the better part of 50 years. There are substantial problems even if such a standard did exist (and many have tried), because of the inherent distributed computing problems. Distributed computing requires that systems make tradeoffs, and the semantics of those tradeoffs must be present in the interface. With a local library call, you get all of 1) consistency, 2) availability, and 3) partition tolerance to failure. In a distributed system, that interface must choose which combination of AP, CP, or theoretically suboptimal (not quite AP, not quite CP) mode it wants. The consumer of the interface must negotiate with the provider of that service to enforce these guarantees. In 1994, Sun Microsystems wrote a classic paper why common RPC systems were not the norm at [1]. [1] https://github.com/papers-we-love/papers-we-love/blob/master/distributed_systems/a-note-on-distributed-computing.pdf https://github.com/papers-we-love/papers-we-love/blob/master...

mpweiher 8y ago

> utopia in which software would plug together via function/procedure/method calls Hmm...The Fine Article actually argues that procedure calls are too low level for software interconnection, and that is the major reason why we aren't there. (and they haven't really improved in the last quarter century since the article was written). Like the analogy in the title of using assembly language to build large-scale software systems. But you're right that the alternatives are also often quite messy; talking to other systems is generally not considered a first class concern, but rather something you cobble together, somehow, out of parts that aren't necessarily fit for purpose. And I think there are actually good reasons for using web and file APIs (composability, simple GET/PUT semantics) that are independent of other aspects (using HTTP, OS mediation...) but come together in one package. My Objective-Smalltalk[1] is an attempt to build a language where these concerns are first class and separated out, for example with Polymorphic Identifiers[2] to generalise resource/variable access, Constraint Connectors[3] and Object Filters to generalise dataflow and Higher Order Messaging[4] to generalise messaging/procedure calls. One interesting outcome is that once you see these more general concepts in a "pure" setting, you can bring them back to other languages, for examples "Stores"[5]. Not quite as nice as with proper language support, but still very useful. [1] http://objective.st http://objective.st [2] https://dl.acm.org/citation.cfm?id=2508168.2508169 https://dl.acm.org/citation.cfm?id=2508168.2508169 https://www.hpi.uni-potsdam.de/hirschfeld/publications/media/WeiherHirschfeld_2013_PolymorphicIdentifiersUniformResourceAccessInObjectiveSmalltalk_AcmDL.pdf [3] https://dl.acm.org/citation.cfm?id=2889456 https://dl.acm.org/citation.cfm?id=2889456 https://www.hpi.uni-potsdam.de/hirschfeld/publications/media/WeiherHirschfeld_2016_ConstraintsAsPolymorphicConnectors_AuthorsVersion.pdf [4] https://en.wikipedia.org/wiki/Higher_order_message https://en.wikipedia.org/wiki/Higher_order_message [5] https://github.com/mpw/MPWFoundation/blob/master/Documentation/Stores.md https://github.com/mpw/MPWFoundation/blob/master/Documentati...

pubby 8y ago

Type systems, exception handlers, garbage collectors, allocators, etc from different languages are rarely compatible with each other.

mpweiher 8y ago
Yeah, another reason why we like to user serialised representations to talk to each other.

abernard1 8y ago

This thought has been around for the better part of 50 years. There are substantial problems even if such a standard did exist (and many have tried), because of the inherent distributed computing problems. Distributed computing requires that systems make tradeoffs, and the semantics of those tradeoffs must be present in the interface. With a local library call, you get all of 1) consistency, 2) availability, and 3) partition tolerance to failure. In a distributed system, that interface must choose which combination of AP, CP, or theoretically suboptimal (not quite AP, not quite CP) mode it wants. The consumer of the interface must negotiate with the provider of that service to enforce these guarantees. In 1994, Sun Microsystems wrote a classic paper why common RPC systems were not the norm at [1]. [1] https://github.com/papers-we-love/papers-we-love/blob/master/distributed_systems/a-note-on-distributed-computing.pdf https://github.com/papers-we-love/papers-we-love/blob/master...