4 ms·

Well duh. We’ve been sold object oriented platforms for decades with the insistence that everything is an object, hiding its internals from the world. There was

by pacala 8y ago

Well duh. We’ve been sold object oriented platforms for decades with the insistence that everything is an object, hiding its internals from the world. There was tepid support for representing plain data. At the heyday of the madness people were busy building object-over-network abominations like CORBA. Even today, the most popular enterprise platform, Java, does not support value types. In the free world, the widely used Python platform has added dataclasses only as recent as 3.7, the current version. No wonder OO style is widely overused.

contextfree 8y ago
isn't "object over network" basically microservices?
- pacala 8y ago
  No! Micro services are value-over-network, hopefully with idempotent semantics. CORBA is object-over-network, with clients holding references to server objects and a protocol that passes around object references over the network. It is true that one can do value-over-network within a CORBA environment by throwing away 95% of the features, but that is not idiomatic CORBA and was sneered upon as not object-oriented enough. This is a case of too many misguided features misleading users down unproductive paths, possibly even worse than selling [a-z0-9_ ]* as the ultimate programming language on account that there are subsets of this language that are actually useful. http://www-cs-students.stanford.edu/~dbfaria/quals/summaries/Coulouris-chap5.txt http://www-cs-students.stanford.edu/~dbfaria/quals/summaries...
  - pjmlp 8y ago
    Quite right, micro-services are the millennials rediscovering SUN RPC and XML RPC, while writing spaghetti structured code with a network in the middle.
- discreteevent 8y ago
  No. Microservices pass data over the network. Distributed objects get handles to remote objects and then make calls to them. Sometimes there could be very many of them and it all got very complex and had poor performance. Microservices are still object oriented because each service is an object and the data being passed is a message. They are big objects. Alan Kay said that one if the mistakes with OO was not making objects bigger.
  - 0815test 8y ago
    CORBA actually supports both "object handle over network" and "ship some actual local object as part of a request/response". It's basically a way of addressing typical FFI/IPC concerns in a way that's actually network- and location-transparent, and that thus also addresses the concerns of distributed programming (for example, making something network-transparent introduces network faults as a possibility, and your system needs to deal with them appropriately!)
  - pacala 8y ago
    Indeed, objects should have been larger. As large as a module. Perhaps with interfaces implemented by different concrete modules. Like non-oo programming language were doing, circa late 80s [modula 3, sml]. While at that, “message passing” [aka goto with arguments] is too fine grained of a concept, what people need 99% of the time is a structured function call.
- nurettin 8y ago
  It could be, if you also send the entire object with all its dependencies along with a remote procedure call. Kinda expensive and misses the point, though.
stcredzero 8y ago
At the heyday of the madness people were busy building object-over-network abominations like CORBA. There was even an unpleasant period of time in the 90's when people tried to make some of the Linux OS distro end-user apps run off of CORBA to bring about the interconnected "sea of objects" vision, slowing things down a lot. No wonder OO style is widely overused. It's overused in part, because it's easily sold. It's easy to make sound-bites out of the doctrine. At the same time, it's a bit nebulous and it's easy to describe all of reality this way at first glance. (That said, in the right hands, it can make for some dandy, clean software. The tricky part is the "right hands.") Basically, software is organizational politics. Software methodologies are dogma, with nothing to back them up, except maybe some savvy design and at times some mathematics. However, these aren't sufficient to deal with the complexities brought in by business needs, the real world, and the complications of developer communities. We're back in the alchemy days of the programming discipline. This is perhaps why minimalism often rules the day. Do as little as possible. Make do with as little as possible. Make apps and modules as small as possible. As much as possible, do no harm.
- deleted 8y ago
  [deleted]
- 0815test 8y ago
  > There was even an unpleasant period of time in the 90's when people tried to make some of the Linux OS distro end-user apps run off of CORBA to bring about the interconnected "sea of objects" vision, slowing things down a lot. That was a thing on the GNOME desktop (GNOME being short for GNU Networked Object Model Environment). The CORBA framework was called bonobo, and it was basically a very early version of what's now achieved via dbus. KDE had its own equivalent, known as DCOP. AIUI, both systems were replaced altogether when dbus became a thing.
- smileypete 8y ago
  >Basically, software is organizational politics. I'd go further to say that software management is (often, mostly?) organizational politics. Software itself is about the flow of control and data, trouble often follows where dogma obscures this fundamental.

by pacala 8y ago

contextfree 8y ago

isn't "object over network" basically microservices?

pacala 8y ago
No! Micro services are value-over-network, hopefully with idempotent semantics. CORBA is object-over-network, with clients holding references to server objects and a protocol that passes around object references over the network. It is true that one can do value-over-network within a CORBA environment by throwing away 95% of the features, but that is not idiomatic CORBA and was sneered upon as not object-oriented enough. This is a case of too many misguided features misleading users down unproductive paths, possibly even worse than selling [a-z0-9_ ]* as the ultimate programming language on account that there are subsets of this language that are actually useful. http://www-cs-students.stanford.edu/~dbfaria/quals/summaries/Coulouris-chap5.txt http://www-cs-students.stanford.edu/~dbfaria/quals/summaries...
- pjmlp 8y ago
  Quite right, micro-services are the millennials rediscovering SUN RPC and XML RPC, while writing spaghetti structured code with a network in the middle.
discreteevent 8y ago
No. Microservices pass data over the network. Distributed objects get handles to remote objects and then make calls to them. Sometimes there could be very many of them and it all got very complex and had poor performance. Microservices are still object oriented because each service is an object and the data being passed is a message. They are big objects. Alan Kay said that one if the mistakes with OO was not making objects bigger.
- 0815test 8y ago
  CORBA actually supports both "object handle over network" and "ship some actual local object as part of a request/response". It's basically a way of addressing typical FFI/IPC concerns in a way that's actually network- and location-transparent, and that thus also addresses the concerns of distributed programming (for example, making something network-transparent introduces network faults as a possibility, and your system needs to deal with them appropriately!)
- pacala 8y ago
  Indeed, objects should have been larger. As large as a module. Perhaps with interfaces implemented by different concrete modules. Like non-oo programming language were doing, circa late 80s [modula 3, sml]. While at that, “message passing” [aka goto with arguments] is too fine grained of a concept, what people need 99% of the time is a structured function call.
nurettin 8y ago
It could be, if you also send the entire object with all its dependencies along with a remote procedure call. Kinda expensive and misses the point, though.

stcredzero 8y ago

At the heyday of the madness people were busy building object-over-network abominations like CORBA. There was even an unpleasant period of time in the 90's when people tried to make some of the Linux OS distro end-user apps run off of CORBA to bring about the interconnected "sea of objects" vision, slowing things down a lot. No wonder OO style is widely overused. It's overused in part, because it's easily sold. It's easy to make sound-bites out of the doctrine. At the same time, it's a bit nebulous and it's easy to describe all of reality this way at first glance. (That said, in the right hands, it can make for some dandy, clean software. The tricky part is the "right hands.") Basically, software is organizational politics. Software methodologies are dogma, with nothing to back them up, except maybe some savvy design and at times some mathematics. However, these aren't sufficient to deal with the complexities brought in by business needs, the real world, and the complications of developer communities. We're back in the alchemy days of the programming discipline. This is perhaps why minimalism often rules the day. Do as little as possible. Make do with as little as possible. Make apps and modules as small as possible. As much as possible, do no harm.

deleted 8y ago
[deleted]
0815test 8y ago
> There was even an unpleasant period of time in the 90's when people tried to make some of the Linux OS distro end-user apps run off of CORBA to bring about the interconnected "sea of objects" vision, slowing things down a lot. That was a thing on the GNOME desktop (GNOME being short for GNU Networked Object Model Environment). The CORBA framework was called bonobo, and it was basically a very early version of what's now achieved via dbus. KDE had its own equivalent, known as DCOP. AIUI, both systems were replaced altogether when dbus became a thing.
smileypete 8y ago
>Basically, software is organizational politics. I'd go further to say that software management is (often, mostly?) organizational politics. Software itself is about the flow of control and data, trouble often follows where dogma obscures this fundamental.