The procedure call may have been one of the greatest inventions of all time, at least as far as computer programming goes. When was it invented?

Here’s a history of calling support that Mark Smotherman put together: Subroutine and procedure call support.

It looks like the subroutine came first, and only after many years did it evolve into a procedure call (e.g. passing parameters). Alan Turing in 1946 and David Wheeler in 1947 are the first ones to mention ways to invoke subroutines; it became formalized in machine architecture in 1951, parameters were passed (albeit inline in code) in 1955, and by 1963 machine architectures were stack-based, which would finally allow for multiple threads of execution.

So it took something like 17 years for procedure calls to evolve into usable form.

Remote procedure calls sprang into being much more quickly, and have been a drag on our thinking and processing ever since. The main reason is that procedure calling never fails (absent whole-world catastrophe that’s not something you check for), whereas remote procedure calling itself can fail quite easily, and you have to check for that – but you don’t, because you are used to procedure calls being perfectly reliable. It’s math -> physics -> biology.

RPC was proposed in RFC 707:  A High-Level Framework for Network-Based Resource Sharing, in 1976.,

A Critique of the Remote Procedure Call Paradigm

Communication Primitives for Ubiquitous Systems or RPC Considered
Harmful

Convenience over correctness

Steve Vinoski’s blog has lots of rants against RPC http://steve.vinoski.net/blog.

RPC is a specific approach for developing networked applications where local calls wrap and hide operations that happen to be carried out on another system across the network. The worst and original form is a blocking, synchronous invocation and has the syntax of a statically bound procedural invocation where the procedure acts on an ordered list of formal parameters and returns a result.

Pure RPC is bad. But even impure RPC affects your thinking.

For example, the so-called two-army problem: there is no way to acknowledge the end of a communication, because an ack or an ack to an ack (and to infinity) can be lost.

Great quote from a Lambda The Ultimate thread

RPC schemes aren’t entirely useless. They work pretty well for essentially trivial problems, which make up most of the situations that people who use them get into. But as soon as you go beyond a simple query/response, they are looking at stuffing 20 pounds of potatos into a 10 pound potato-capacity bag, and fixing all the “impedance mismatch” problems in the world only expands the capacity to 12.5 pounds.

Message Passing, Remote Procedure Calls and Distributed Shared Memory as Communication Paradigms for Distributed Systems

Message Passing vs Remote Procedure Call

RPC vs Messaging

The case: RPC vs. Messaging.

Promises and futures are ways that people have tried to fix remote procedure calls.

Promises: Linguistic Support for Efficient Asynchronous Procedure Calls in Distributed Systems