> The mental image was one of separate computers sending requests to other computers that had to be accepted and understood by the receivers before anything could happen. In today's terms every object would be a server offering services whose deployment and discretion depended entirely on the server's notion of relationship with the server.
1993 called and wants its micro-services. That is great. At least it seems like he is describing Go's channels, Rust's tasks, and most of all Erlang's processes.
It is interesting, perhaps it is a reflection on how some of these concepts are abstract that anything can be read into it, but it seems that the initial design and motivation behind OO has been perverted by C++ and Java.
I started with C++ and Java in college. To me OO was inheritance, composition, and polymorphism, and so on. Years later, when distributed and scalable computing is talked about other languages and platforms seems more OO than the classic OO.
And finally one more excerpt:
>
---
1. Everything is an object
2. Objects communicate by sending and receiving messages (in terms of objects) Objects have their own memory (in terms of objects)
3. Every object is an instance of a class (which must be an object) The class holds the shared behavior for its instances (in the form of objects in a program list)
---
Pretty funny. Replace 'object' with 'process' and you have Erlang, the last language you'd call OO : 1) everything is a process 2) processes sending messages to each other. Each process has an isolated heap (won memory). 3) Functions in modules hold the shared behavior of many possible process instances spawn from it.
"Where does the special efficiency of object-oriented design come from? This is a good question given that it can be viewed as a slightly different way to apply procedures to data-structures. Part of the effect comes from a much clearer way to represent a complex system. Here, the constraints are as useful as the generalities. Four techniques used together — persistent state, polymorphism, instantiation, and methods-as-goals for the object — account for much of the power. None of these require an "object-oriented language" to be employed — ALGOL 68 can almost be turned to this style — an OOPL merely focuses the designer's mind in a particular fruitful direction. However, doing encapsulation right is a commitment not just to abstraction of state, but to eliminate state oriented metaphors from programming."
>1993 called and wants its micro-services. That is great. At least it seems like he is describing Go's channels, Rust's tasks, and most of all Erlang's processes.
Hmm, don't know about the others, but Go's channels seem much much more primitive and bare than the description you quoted.
1993 called and wants its micro-services. That is great. At least it seems like he is describing Go's channels, Rust's tasks, and most of all Erlang's processes.
It is interesting, perhaps it is a reflection on how some of these concepts are abstract that anything can be read into it, but it seems that the initial design and motivation behind OO has been perverted by C++ and Java.
I started with C++ and Java in college. To me OO was inheritance, composition, and polymorphism, and so on. Years later, when distributed and scalable computing is talked about other languages and platforms seems more OO than the classic OO.
And finally one more excerpt:
>
---
---Pretty funny. Replace 'object' with 'process' and you have Erlang, the last language you'd call OO : 1) everything is a process 2) processes sending messages to each other. Each process has an isolated heap (won memory). 3) Functions in modules hold the shared behavior of many possible process instances spawn from it.