像我在最近的专栏中说过的一样：

复杂的分层需要维护漏洞百出的本地/远程的透明调用的幻觉，让人想起哥白尼之前的天文学家，是如何用复杂的等式来解释太阳，以及其他的星球是怎样绕地球旋转的。

使用C++，JAVA等语言的RPC系统也尝试使用比分布式系统更高度的连接性(coupling)。代表性的，一些接口定义语言(IDL)可以用来自动生成stubs/proxies/skeletons的代码–这些代码将本地调用转化为远程调用，但是没有人愿意自己手写或者维护这些代码。如果使用了别的IDL你需要重新生成代码，重新编译，重新测试，重新发布你的程序，而且你必须原子性的做这些操作，全部都重新来过或者一点都不改动–版本号是主要原因。在一个已经交付实施的产品系统中，全部系统中原子性(atomic)的升级需要巨大艰辛的工作量。总的来说，这种方法会产生易破碎的，高度耦合性(tightly-coupled)的系统。

这些系统在将IDL和你所采用的语言之间进行翻译时也会产生类型(type)不匹配的问题。如果一个IDL是极小的语言所以可以被很多程序语言采用，那么一些高级语言的特性(例如c++,java)就不能被使用。而当你将IDL语言强化，使他更接近高级语言时，将它翻译成C或者其他的更基础的语言就变的非常困难。更主要的问题是，无论你如何设计IDL的类型(type)系统，所有的系统不会–实时上是不能–清晰的映射到需要的程序语言中。这些导致在一个或更多的支持的编程语言中使用不符合习惯的编程，使用那些语言的开发者会很抱怨。如果你采用了特定的语言例如JAVA作为你的RPC IDL语言来解决类型不匹配问题，这样做只会对着一种语言有效，对于其他的语言仍是异常艰难。

仍有一些需求要求网线的两端的系统采用同样或者相似的底层架构。早期的程序员经常对此抱怨，例如当他们提起需要在所有程序底层架构中使用CORBA ORBs。如果你不能在所有的终端中采用绝对一致的底层架构，那么你需要架设在互用性标准上的可以互相操作的底层架构。这些，不幸的也是经常性的问题。CORBA的互相协作性最终表现的非常好–但是经过了10年的发展才达到。CORBA是从没有任何互相协作协议开始发展的(事实上最初它甚至没有列出任何网络协议)，当我们忍受了数年的互相协作问题后，IIOP出现，然后两个协议和实现才都变得成熟了。

最终，RPC是一个漏洞百出的抽象(abstraction)，它不能隐藏想要隐藏的，因此，它添加更多意外的复杂的做法可以轻易的将所有的问题变的更难处理。

在我之前的消息中我提到ERLANG采用了正确的解决办法。我认为这样做是对的，不仅因为它高效，直接的处理分布式，也是因为ERLANG没有向开发者隐藏这些难解决的问题。它通过提供处理超时，出错，版本号问题的特性来使程序员注意这些问题。严格意义上来说，ERLANG没有提供RPC，因为远程调用并不能真的看起来像本地调用一样。