Alan Kay on the Meaning of “Object-Oriented Programming” (2003)
1–10 of 58 posts
Re: Alan Kay on the Meaning of “Object-Oriented Programming” (2003)
#2In fact, the origins of OOP are basically what we would now call microservice architecture (CSP-inspired languages like Go being a specialisation of this). Each service can be as stateless or as stateful as it needs to be (without shared state) and services should be loosely coupled.
That's quite different to most large-scale OOP architectures, but it is possible to code in that style in any OOP language.
Heavy reliance on inheritance for code reuse is a whole problem class in itself that again has little to do with OOP and lots to do with the influence of C++.
Re: Alan Kay on the Meaning of “Object-Oriented Programming” (2003)
#3 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.
Can somebody explain to me what distinction he's drawing here? What's the issue with RPC that's solved by Objects+Messages?Re: Alan Kay on the Meaning of “Object-Oriented Programming” (2003)
#4Towards the end: 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. Can somebody explain to me what distinction he's drawing here? What's the issue with RPC that's solved by Objects+Messages?
Re: Alan Kay on the Meaning of “Object-Oriented Programming” (2003)
#5Bam. That is it right there. Java really messed this up.
Strong static typing and OO is an abomination.
Re: Alan Kay on the Meaning of “Object-Oriented Programming” (2003)
#6Re: Alan Kay on the Meaning of “Object-Oriented Programming” (2003)
#7Towards the end: 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. Can somebody explain to me what distinction he's drawing here? What's the issue with RPC that's solved by Objects+Messages?
I understand this passage as a comment on philosophical approach. You can see the same interaction as a "Remote Procedure Call" or as "sending a message to an object".
Re: Alan Kay on the Meaning of “Object-Oriented Programming” (2003)
#8Towards the end: 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. Can somebody explain to me what distinction he's drawing here? What's the issue with RPC that's solved by Objects+Messages?
Re: Alan Kay on the Meaning of “Object-Oriented Programming” (2003)
#9A lot of the recent trend towards OOP-bashing comes from bad implementations of OOP, just as bashing design patterns is more to do with badly thought out architectures and overuse of those patterns. In fact, the origins of OOP are basically what we would now call microservice architecture (CSP-inspired languages like Go being a specialisation of this). Each service can be as stateless or as stateful as it needs to be…
Re: Alan Kay on the Meaning of “Object-Oriented Programming” (2003)
#10Towards the end: 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. Can somebody explain to me what distinction he's drawing here? What's the issue with RPC that's solved by Objects+Messages?
A remote procedure call blocks on the response, ensuring the system is only as strong as its weakest link. If every object communicates asynchronously with every other object, using messages instead of shared memory (hence avoiding locking issues), the design by necessity evolves in ways which becomes more robust and easy to scale. Synchronous RPC calls encourage unscalable and unreliable architectures.