Here’s a good post by Steve Vinoski on why RPCs are a bad idea. I couldn’t agree more.

Ten years ago I worked on a project that used DCOM for communication between the client and the server. The amount of pain that caused was tremendous. That led me to make the same conclusion that Steve made: RPCs are fundamentally flawed because they don’t expose failure modes to the programmer directly.

However the industry marched on continued delivering these failed technologies. CORBA is still alive and kicking, and both Java and .NET provide remoting libraries.

The problem has been patched somewhat by adding asynchronous calls to these RPC libraries, but the whole idiotic idea of sending object graphs instead of plain messages over the wire is still alive and kicking.

You can also try to use various RPC technologies as a simple message passing technology by using asynchronous calls as messages with parameters being passed by value, but various little details (versioning, object lifetimes, performance, etc.) will still bite you in the ass so why bother?

The first time people try to use functional languages like ML or Haskell, they’re like, “dude, where’s my parenthesis”. The syntax irks them because they are used to calling a function f like this:

f (1, 2)

while in those languages it’s simply:

f 1 2

Now thankfully C# programmers are exposed to lambdas more than before, so the jump in understanding doesn’t have to be so big as there are a few stepping stones in between.

Take this simple lambda and assign it to a Func<int, int, int> f1:

(x, y) => x + y

You’d call this function simply by saying:

f1 (1, 2)

But it’s effectively equivalent to the following lambda which we’ll assign to Func<int, Func<int, int>> f2:

x => y => x + y

which you would call by writing:

f2 (1) (2)

Now in functional language all functions you write effectively take the second form. And in this form the parenthesis are superfluous, as nobody wants to write:

f (1) (2) (3) (4)

when they can write:

f 1 2 3 4