4 ms·

In my experience, the thing that's wrong about object-oriented programming is not the object-orientation itself, but the over-application of it. - Sometimes mo

In my experience, the thing that's wrong about object-oriented programming is not the object-orientation itself, but the over-application of it. - Sometimes more "procedural" programming provides better clarity. At other times, object-orientation is a cleaner approach. Neither should be a replacement for the other at all times. - The idea that objects should reflect how we think of real objects in the physical world probably needs to die, or at least not be treated as a standard for object orientation, since objects in reality often do not fit into neat categories and hierarchies. Because reality is dirty, as is virtual reality, unanticipated exceptions to the rules end up causing OO zealots to create hack solutions that end up being rigid and less obvious to other programmers. The simplest example I can think of off the top of my head is the Fat Model Skinny Controller paradigm in MVC programming; since a model is often looked at as a representation of real-world objects, a programmer thinking in OO is likely to stick every conceivable property and behavior around the imaginary object into the model code, which sometimes results in files thousands of lines long with code that doesn't need to have anything to do with database abstraction. In such cases, a lot of code related to the concept behind a model would be better handled by helper functions or other classes.

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!)
- 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.
scarface74 8y ago
One of the seminal books that people read about object modeling “Domain Driven Design” by Eric Evans writes about “transaction scripts”. Not everything needs to be modeled.
- stcredzero 8y ago
  Not everything needs to be modeled. The thing about Smalltalk, is that it adheres very closely to "everything is an object." This means that even low level mechanisms in Smalltalk have to allow a very nimble use of objects. This means that there can be serious cost/benefit mismatches when translating libraries/patterns/designs from languages like Smalltalk to others. Creating a lambda in Smalltalk is trivial business as usual. Other environments require more thought, have more limitations, have higher costs of their use. Factories are how you do normal operations in Smalltalk. In other languages, they become infrastructure that needs to be maintained. Not everything needs to be modeled in every language. Basically, you model to the point where the cost/benefit works out, but go no further. In Smalltalk, the cost of modeling things is designed to be so low, almost everything is an object. So of course, the cost/benefit in different environments can be drastically different, and in many, modeling everything can be a waste.
stcredzero 8y ago
In my experience, the thing that's wrong about object-oriented programming is not the object-orientation itself, but the over-application of it. Or the misapplication of it. If an app is really about dataflow, but programmers have tried to shoehorn in a pedantic OO model, one can often end up with lots of nouns with names that talk about How (exposing too much detail) and lots of code that serves to stick data in this cubby, with other code taking that data out, then sticking it into another cubby, ad nauseum. In that case, the relationships between the cubbyholes, the data, and the dataflow are only maintained through naming conventions, which can in turn be misapplied or neglected. This makes following the dataflow into detective work to circumvent missed naming conventions, where it should really just be following implementers/senders/references in the standard way provided for by the language. since a model is often looked at as a representation of real-world objects, a programmer thinking in OO is likely to stick every conceivable property and behavior around the imaginary object into the model code This is where YAGNI comes into play. (You Ain't Gonna Need It) Never implement something unless you have empirical data to back up the need. If you implement according to imagination... well, the imagination of creative tech people is often practically unbounded. So just imagine how badly scaled the result could be.
agumonkey 8y ago
Point 2 rings true to me. The idea that you could model reality in a layman manner is borderline madness for engineering. You want to encode invariants and properties that are far from the superficial taxonomies you get fed in school. Object orientation can provide a cute encoding of abstraction layers ala SICP to avoid dealing with a bunch of dangling functions:
platz 8y ago
But, what do you think of the specific points that were made in the video (not the title)? Are they not worthy of discussion, since, ostensibly that is why we are here?

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!)
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.

scarface74 8y ago

One of the seminal books that people read about object modeling “Domain Driven Design” by Eric Evans writes about “transaction scripts”. Not everything needs to be modeled.

stcredzero 8y ago
Not everything needs to be modeled. The thing about Smalltalk, is that it adheres very closely to "everything is an object." This means that even low level mechanisms in Smalltalk have to allow a very nimble use of objects. This means that there can be serious cost/benefit mismatches when translating libraries/patterns/designs from languages like Smalltalk to others. Creating a lambda in Smalltalk is trivial business as usual. Other environments require more thought, have more limitations, have higher costs of their use. Factories are how you do normal operations in Smalltalk. In other languages, they become infrastructure that needs to be maintained. Not everything needs to be modeled in every language. Basically, you model to the point where the cost/benefit works out, but go no further. In Smalltalk, the cost of modeling things is designed to be so low, almost everything is an object. So of course, the cost/benefit in different environments can be drastically different, and in many, modeling everything can be a waste.

stcredzero 8y ago

In my experience, the thing that's wrong about object-oriented programming is not the object-orientation itself, but the over-application of it. Or the misapplication of it. If an app is really about dataflow, but programmers have tried to shoehorn in a pedantic OO model, one can often end up with lots of nouns with names that talk about How (exposing too much detail) and lots of code that serves to stick data in this cubby, with other code taking that data out, then sticking it into another cubby, ad nauseum. In that case, the relationships between the cubbyholes, the data, and the dataflow are only maintained through naming conventions, which can in turn be misapplied or neglected. This makes following the dataflow into detective work to circumvent missed naming conventions, where it should really just be following implementers/senders/references in the standard way provided for by the language. since a model is often looked at as a representation of real-world objects, a programmer thinking in OO is likely to stick every conceivable property and behavior around the imaginary object into the model code This is where YAGNI comes into play. (You Ain't Gonna Need It) Never implement something unless you have empirical data to back up the need. If you implement according to imagination... well, the imagination of creative tech people is often practically unbounded. So just imagine how badly scaled the result could be.

agumonkey 8y ago

Point 2 rings true to me. The idea that you could model reality in a layman manner is borderline madness for engineering. You want to encode invariants and properties that are far from the superficial taxonomies you get fed in school. Object orientation can provide a cute encoding of abstraction layers ala SICP to avoid dealing with a bunch of dangling functions:

platz 8y ago

But, what do you think of the specific points that were made in the video (not the title)? Are they not worthy of discussion, since, ostensibly that is why we are here?