|
|
|
|
|
|
by skybrian
2578 days ago
|
|
|
I think some of the confusion here is that code you can't see or change is typically running on a different server, while ordinary method calls are typically about in-process communication. Compile-time checking makes sense for avoiding problems within code that's all going to be compiled together. Runtime error recovery makes sense for remote procedure calls. And there are also situations where you have untrusted code loaded dynamically (JavaScript in a browser). It seems pretty important to be clear about static assumptions you can trust (because it's compiled in) versus things that can change. |
|
|
http://mythz.servicestack.net/blog/2013/02/27/the-deep-insig...
mythz> On RPC, and how it distorts developers mindsets in architecting and building systems:
Kay> The people who liked objects as non-data were smaller in number, and included myself, Carl Hewitt, Dave Reed and a few others – pretty much all of this group were from the ARPA community and were involved in one way or another with the design of ARPAnet->Internet in which the basic unit of computation was a whole computer. But just to show how stubbornly an idea can hang on, all through the seventies and eighties, there were many people who tried to get by with “Remote Procedure Call” instead of thinking about objects and messages. Sic transit gloria mundi.
mythz> Carl Hewitt being the inventor of the Actor Model and Dave Reed who was involved in the early development of TCP/IP and the designer of UDP.
mythz> The last latin phrase translates to “Thus passes the glory of the world” - expressing his dismay on what might have been.
He also doesn't consider accessing a data field called "entire_name" to be "object oriented programming". He calls that "simulated data structure programming".
https://computinged.wordpress.com/2010/09/15/alan-kay-on-mot...
Kay> If you are “setting” values from the outside of an object, you are doing “simulated data structure programming” rather than object oriented programming. One of my original motivations for trying to invent OOP was to eliminate imperative assignment (at least as a global unprotected action). “Real OOP” is much more about “requests”, and the more the requests invoke goals the object knows how to accomplish, the better. “Abstract Data Types” is not OOP!