9 ms·

As a professional dev who has made a career out of working in oop languages and codebases, it took me far too long to realize that when it comes to oop, the emp

by bedobi 3y ago

As a professional dev who has made a career out of working in oop languages and codebases, it took me far too long to realize that when it comes to oop, the emperor has no clothes. To this day, oop advocates can't even agree on what oop even is or means. Apparently oop as envisioned by Alan Kay was supposed to work like cells in the body that pass messages between each other and take actions independently. Why? Who knows! It was never really explained why literally one of the most complex systems imaginable, one that we still really have very little idea how it even works, should be the model for what could and should probably be a lot simpler. Today's modern oop languages are probably very far from what Kay envisioned (whatever that was), but it's remains unclear why classes and objects are "better" than the alternatives. And before anyone goes and comments aksully code organization blabla like yes but code organization can be great or shit in oop or fp or procedural codebases, it has nothing to do with the "paradigm". Let alone that the entrenched, canonical, idiomatic coding styles of most modern oop languages encourage state, mutability, nulls, exceptions and god knows how many trivially preventable entire classes of errors. Granted, most have now started to come around and are adopting more fp features and ideas every year, but still. Don't get me wrong, writing programs like cells in the body that pass messages between each other and take actions independently is an interesting idea which deserves pursuing, if nothing else but to satisfy our curiosity and seeing to what if anything it's applicable and suited. (and even if the answer turns out to be "nothing", we've still learned something!) But going from there to making strong claims about it being a more or less universally superior paradigm for computing and writing code, with little to zero evidence, that's a huge, huge stretch. To the degree Erlang and Actors work, I think that's kind of a happy coincidence, and not due to any rigorous work on Alan Kay's part.

Akronymus 3y ago
> Why? Who knows! It was never really explained why literally one of the most complex systems imaginable, one that we still really have very little idea how it even works, should be the model for what could and should probably be a lot simpler. From my understanding, it is that every object has a very limited set of functionalities it manages. And that a goal is for each object to know as little as possible of the outside world. And along with that, to not bind to specific objects/classes but to bind to specific messages (Including multiple dispatch)
- Fire-Dragon-DoL 3y ago
  That was poorly achieved with oop and better achieved with fp though. Oop couples functionality and data (not typescript, if you don't want)
javajosh 3y ago
>Apparently oop as envisioned by Alan Kay was supposed to work like cells in the body that pass messages between each other and take actions independently. IIRC he was interested in an abstraction that worked "all the way up" - he wanted the abstraction to essentially be a tiny computer. It's a cool idea with a lot of power. But it really is too powerful for applications, and leads to the same complexity problems you get in large distributed systems. And to not have 'function' as a primitive is inexcusable in any language. Java's lack of a function primitive is a key weakness. It means you must have at least one "utility class" per project - a public class with static methods that are themselves simple functions. (The relatively recent introduction of lambdas, or anonymous inner classes, does not really address the problem. That's just ugly syntax sugar).
- jayd16 3y ago
  Is the fact that static methods in Java need to be namespaced to a class really anything to even worry about? Like, whats even a single issue with it?
  - deleted 3y ago
    [deleted]
  - brianide 3y ago
    Personally issue with it (besides the pointless noise of having to make a private constructor and such) is that you can't alias them like you can with actual namespaces/modules in most languages, which becomes a pain when eg. you need functions from both Apache's StringUtils and your own StringUtils in the same file.
    - jayd16 3y ago
      Ah, I suppose it can get wordy in Java. I'm more used to C# where you can alias the class name if need be.
  - extasia 3y ago
    Theres an argument that it teaches new programmers poor habits.
goatlover 3y ago
And yet despite all these criticisms and complaints, C++, Java, Python, Javascript, PHP and even Ruby to some extent, have been massively popular and used to write all sorts of software we rely on.
- namaria 3y ago
  What people are complaining about when they voice these sorts of concerns goes back to the concept of essential vs accidental complexity proposed by Fred Brooks. The issue is not that adding accidental, inessential complexity to software is somehow a sin. The problem is that someone will have to wrangle this extra complexity. Enterprises can just throw bodies at the problem, creating drudgery. The warning is against producing pointless, boring work.
- patmorgan23 3y ago
  All of those languages also have functional/procedural language features. You don't have to go crazy with Classes/Objects to program in them.
  - zeroimpl 3y ago
    Which is what’s great about these languages - best of both worlds. I also think this discussion shouldn’t be about languages at all, you can have objects of some form in any imperative language including C. It’s more about what design patterns make sense for specific problems, and sometimes the answer is OO-style (eg with class hierarchies) and sometimes not.
- 12345hn6789 3y ago
  (nobody is talking about whether X pattern can be used successfully)
willio58 3y ago
I remember learning and using OOP in computer science classes and then going to apply it to a game I was working on. I object-ified everything! It felt like it all just made sense. Then I ran the game. And it crawled at 15fps and I wondered why. Of course I was new to programming so I can’t just blame OOP but it was my first lesson in how OOP isn’t a magic wand by any means. And later I got into more functional programming and today I find myself writing function-based components in react for a living and loving it. It’s funny how things go like that.
fassssst 3y ago
I like the mapping to Claude Shannon’s ideas in information theory. https://cs.stanford.edu/people/eroberts/courses/soco/projects/1999-00/information-theory/history.html https://cs.stanford.edu/people/eroberts/courses/soco/project...
MetaWhirledPeas 3y ago
I do some programming, but not OOP. Over the years I've read about it and asked colleagues about it, and the why question finally settled on it helps you organize your code. I can get behind that. But I also want to understand why OOP instead of conventional programming; I'm still waiting for that part to click. Until that question is answered it won't be capturing my full attention.
- hfkwer 3y ago
  What is "conventional programming", pray tell?
  - dragonwriter 3y ago
    Functional? Procedural? Logic? Dataflow? Relational? Unstructured imperative, like old-school BASIC? I mean, the only clue we have is that it is some paradigm that isn’t OO, but that leaves... a whole lof options.
  - dsego 3y ago
    Maybe procedural?
    - KerrAvon 3y ago
      I think the root rant here, which I personally find unconvincing, is thinking in terms of OOP vs functional programming. Procedural isn't the opposite of OO; objects are composed of many procedures.
      - MetaWhirledPeas 3y ago
        I wasn't intending to trigger anyone but it seems I have. Perhaps I should have stated it as, "why OOP instead of organizing the code through other means?" It's a genuine question I have, and it just hasn't clicked for me yet, personally. So it's not really trying to be convincing at all; I'm just sharing my experience.
robocat 3y ago
> oop languages encourage state, mutability, nulls, exceptions and god knows how many trivially preventable entire classes of errors. Granted, most have now started to come around and are adopting more fp features and ideas every year Do functional languages actually discourage "state, mutability, nulls, exceptions" I know why we might argue against these features, but implying that functional programming doesn't have those features seems a little weird (or equivalent e.g. call/cc can cause execution flow less predictable than exceptions)!
- jacobr1 3y ago
  My limited experience with FP languages suggests they encourage very explicit state management. You remove a lot of the footguns from having side-effects all over the place at the cost of the (sometimes, depending on the tooling and your familiarity with it) it being more complex to introduce state or external side-effects when you want them.
- jononomo 3y ago
  Once I got the hang of Elixir/Erlang it was just such a weight off my shoulders, honestly. Programming without entire classes of bugs is so much nicer.
taeric 3y ago
If you think that OOP advocates can't decide on what OOP is, don't look too hard at the FP side of the world. :D Same goes for evidence based ideas. Odds are stupid high that you cannot find a single large scale codebase that has succeeded using any "pure" technique. Heck, I'd take small scale codebase for a fun thing to look at, at this point. Make performance a requirement, and really get ready for tears.
waterhouse 3y ago
Jonathan Rees had said: "Here is an a la carte menu of features or properties that are related to these terms; I have heard OO defined to be many different subsets of this list." The aspects he names: "encapsulation", "protection", "ad hoc polymorphism", "parametric polymorphism", "everything is an object", "all you can do is send a message", "specification inheritance = subtyping", "implementation inheritance/reuse", "sum-of-product-of-function pattern". http://www.paulgraham.com/reesoo.html http://www.paulgraham.com/reesoo.html
MisterTea 3y ago
> Apparently oop as envisioned by Alan Kay was supposed to work like cells in the body that pass messages between each other and take actions independently. When I think of programs I think of modules of code that act like machines on a conveyor belt or assembly line operating on and pushing data along from station to station. This is why Erlang, Go and Plan 9's thread(2) library are how I want to program. > To the degree Erlang and Actors work, I think that's kind of a happy coincidence, and not due to any rigorous work on Alan Kay's part. https://www.infoq.com/interviews/johnson-armstrong-oop/ https://www.infoq.com/interviews/johnson-armstrong-oop/ (3. Is Erlang object oriented?) three points: message passing, isolation between objects, and polymorphism. The industry seems to have ran away with #3 while ignoring #2 and forgetting completely about #1.
- CyberDildonics 3y ago
  What you are describing is what a directed acyclic graph achieves. It works well when you need to do a series of transformations. It does not work well when you need branching, loops and state at a high level. The mistake people make is that they see it work very well for certain parts of their software, then they give in to silver bullet syndrome and try to make it work for everything.
igouy 3y ago
> Apparently oop as envisioned by Alan Kay was supposed to work like cells in the body that pass messages between each other and take actions independently. > Why? Who knows! It was never really explained… Perhaps "Design Principles Behind Smalltalk" ? https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk....
c_crank 3y ago
>Let alone that the entrenched, canonical, idiomatic coding styles of most modern oop languages encourage state, mutability, nulls, exceptions and god knows how many trivially preventable entire classes of errors. Granted, most have now started to come around and are adopting more fp features and ideas every year, but still. State isn't a feature solely of OOP. It's very easy to see the FP craze as a similarly dogmatic insistence on pure everything as removing useful features instead of preventing errors. If FP truly was the indisputable way of the future, Scala would be the CRUDspeak of choice by now.
- Fire-Dragon-DoL 3y ago
  Elixir has opt-in state that works really well! Everything immutable until you need state.
AtlasBarfed 3y ago
Most oop was designed in the context of desktop gui apps, which are much more complex that web apps imo. Is-a vs has-a is a lot more clear in context of widgets and windows. It still isn't perfect, most popular gii used inheritance whereas composition would probably be better. Inheritance ended up as a core component of oop principles when ultimately it is a flawed approach compared to more flexible composition methods. Liskov substitution was a massive success, classes were an improvement over structs, private vs public was generally a good idea even if the astro architects went nuts with it.
friendzis 3y ago
> And before anyone goes and comments aksully code organization blabla I'll bite. Having worked on "enterprise" application the OOP (or more like the dreaded enterprise patterns) have sort of "clicked" to me. An aside. Git-flow is more than decade old at this point and people still have heated debates from time to time on whether that approach is any good. In essence git-flow merely introduces organization to patchsets. If you are building a SaaS like system, most probably every environment you have runs "current" code and each stage (prod, test, dev) is merely a shifted pointer that will eventually catch up. Why would you structure your teamwork around identifiable patchsets, why would you keep that information around when you do trunk-based development? There is seemingly no need to do that and you would rightfully diss on git-flow as overly complex. However, if you build hardware appliances or installable offline application with multiple versions (think e.g. MS Office in 2000-2010 - multiple versions and tiers of those out in the wild under support), suddenly there are situations where you do in fact need to checkout and work on an exact patchset that is installed at customer site. If your field requires any form of certification, you will quickly learn that having patchsets provably not touching frozen (already certified or submitted for certification) code is highly valuable. Ability to cherry-pick a hotfix can save organization man-months. Back to code organization. So you have this "enterprise" application that has various software modules/components, some of which are built by external contractors, some are off-the-shelf components, some have been left and forgotten five years ago and for one reason or another you want to work on one of these components. Whatever team you assemble, majority will have zero understanding of assumptions baked into code. Documentation, however meticulously maintained, will still leave holes in understanding. How do you make changes to a decade old component that is used in various weird ways all throughout the project with any amount of confidence that you are not breaking stuff at a distance? Apparently, OOP enterprise patterns that introduce decoupling points for implementation details and pass around objects with assumptions abstracted away are pretty solid barriers. They are cumbersome, difficult to use at early stages of development when all complexity of the task can fit into the heads of programmers implementing features. Similarly to git-flow, the advantages of these structures only become apparent when you start needing them and that will quite probably be when the principal engineers greenfielding the project have long left the company altogether. A very specific example: factory pattern. Why would you have a layer of indirection to simply instantiate an object? All refcounting shenanigans aside, you just cannot change interface of object/component without affecting call sites. Call sites that may be outside of your control, code frozen or simply too dreadful to touch without strong justification. Factory pattern introduces a decoupling point between call sites and implementation. Having a factory you can implement interface shims and leave call sites untouched while having the freedom to rework component and its interface. You just cannot achieve that without OOP. > Let alone that the entrenched, canonical, idiomatic coding styles of most modern oop languages encourage state, mutability, nulls, exceptions and god knows how many trivially preventable entire classes of errors. I will agree that OOP implementations in mainstream languages leave much to be desired. That is part of the price we pay for backwards compatibility.

by bedobi 3y ago

Akronymus 3y ago

> Why? Who knows! It was never really explained why literally one of the most complex systems imaginable, one that we still really have very little idea how it even works, should be the model for what could and should probably be a lot simpler. From my understanding, it is that every object has a very limited set of functionalities it manages. And that a goal is for each object to know as little as possible of the outside world. And along with that, to not bind to specific objects/classes but to bind to specific messages (Including multiple dispatch)

Fire-Dragon-DoL 3y ago
That was poorly achieved with oop and better achieved with fp though. Oop couples functionality and data (not typescript, if you don't want)

javajosh 3y ago

>Apparently oop as envisioned by Alan Kay was supposed to work like cells in the body that pass messages between each other and take actions independently. IIRC he was interested in an abstraction that worked "all the way up" - he wanted the abstraction to essentially be a tiny computer. It's a cool idea with a lot of power. But it really is too powerful for applications, and leads to the same complexity problems you get in large distributed systems. And to not have 'function' as a primitive is inexcusable in any language. Java's lack of a function primitive is a key weakness. It means you must have at least one "utility class" per project - a public class with static methods that are themselves simple functions. (The relatively recent introduction of lambdas, or anonymous inner classes, does not really address the problem. That's just ugly syntax sugar).

jayd16 3y ago
Is the fact that static methods in Java need to be namespaced to a class really anything to even worry about? Like, whats even a single issue with it?
- deleted 3y ago
  [deleted]
- brianide 3y ago
  Personally issue with it (besides the pointless noise of having to make a private constructor and such) is that you can't alias them like you can with actual namespaces/modules in most languages, which becomes a pain when eg. you need functions from both Apache's StringUtils and your own StringUtils in the same file.
  - jayd16 3y ago
    Ah, I suppose it can get wordy in Java. I'm more used to C# where you can alias the class name if need be.
- extasia 3y ago
  Theres an argument that it teaches new programmers poor habits.

goatlover 3y ago

And yet despite all these criticisms and complaints, C++, Java, Python, Javascript, PHP and even Ruby to some extent, have been massively popular and used to write all sorts of software we rely on.

namaria 3y ago
What people are complaining about when they voice these sorts of concerns goes back to the concept of essential vs accidental complexity proposed by Fred Brooks. The issue is not that adding accidental, inessential complexity to software is somehow a sin. The problem is that someone will have to wrangle this extra complexity. Enterprises can just throw bodies at the problem, creating drudgery. The warning is against producing pointless, boring work.
patmorgan23 3y ago
All of those languages also have functional/procedural language features. You don't have to go crazy with Classes/Objects to program in them.
- zeroimpl 3y ago
  Which is what’s great about these languages - best of both worlds. I also think this discussion shouldn’t be about languages at all, you can have objects of some form in any imperative language including C. It’s more about what design patterns make sense for specific problems, and sometimes the answer is OO-style (eg with class hierarchies) and sometimes not.
12345hn6789 3y ago
(nobody is talking about whether X pattern can be used successfully)

willio58 3y ago

I remember learning and using OOP in computer science classes and then going to apply it to a game I was working on. I object-ified everything! It felt like it all just made sense. Then I ran the game. And it crawled at 15fps and I wondered why. Of course I was new to programming so I can’t just blame OOP but it was my first lesson in how OOP isn’t a magic wand by any means. And later I got into more functional programming and today I find myself writing function-based components in react for a living and loving it. It’s funny how things go like that.

fassssst 3y ago

I like the mapping to Claude Shannon’s ideas in information theory. https://cs.stanford.edu/people/eroberts/courses/soco/projects/1999-00/information-theory/history.html https://cs.stanford.edu/people/eroberts/courses/soco/project...

MetaWhirledPeas 3y ago

I do some programming, but not OOP. Over the years I've read about it and asked colleagues about it, and the why question finally settled on it helps you organize your code. I can get behind that. But I also want to understand why OOP instead of conventional programming; I'm still waiting for that part to click. Until that question is answered it won't be capturing my full attention.

hfkwer 3y ago
What is "conventional programming", pray tell?
- dragonwriter 3y ago
  Functional? Procedural? Logic? Dataflow? Relational? Unstructured imperative, like old-school BASIC? I mean, the only clue we have is that it is some paradigm that isn’t OO, but that leaves... a whole lof options.
- dsego 3y ago
  Maybe procedural?
  - KerrAvon 3y ago
    I think the root rant here, which I personally find unconvincing, is thinking in terms of OOP vs functional programming. Procedural isn't the opposite of OO; objects are composed of many procedures.
    - MetaWhirledPeas 3y ago
      I wasn't intending to trigger anyone but it seems I have. Perhaps I should have stated it as, "why OOP instead of organizing the code through other means?" It's a genuine question I have, and it just hasn't clicked for me yet, personally. So it's not really trying to be convincing at all; I'm just sharing my experience.

robocat 3y ago

> oop languages encourage state, mutability, nulls, exceptions and god knows how many trivially preventable entire classes of errors. Granted, most have now started to come around and are adopting more fp features and ideas every year Do functional languages actually discourage "state, mutability, nulls, exceptions" I know why we might argue against these features, but implying that functional programming doesn't have those features seems a little weird (or equivalent e.g. call/cc can cause execution flow less predictable than exceptions)!

jacobr1 3y ago
My limited experience with FP languages suggests they encourage very explicit state management. You remove a lot of the footguns from having side-effects all over the place at the cost of the (sometimes, depending on the tooling and your familiarity with it) it being more complex to introduce state or external side-effects when you want them.
jononomo 3y ago
Once I got the hang of Elixir/Erlang it was just such a weight off my shoulders, honestly. Programming without entire classes of bugs is so much nicer.

taeric 3y ago

If you think that OOP advocates can't decide on what OOP is, don't look too hard at the FP side of the world. :D Same goes for evidence based ideas. Odds are stupid high that you cannot find a single large scale codebase that has succeeded using any "pure" technique. Heck, I'd take small scale codebase for a fun thing to look at, at this point. Make performance a requirement, and really get ready for tears.

waterhouse 3y ago

Jonathan Rees had said: "Here is an a la carte menu of features or properties that are related to these terms; I have heard OO defined to be many different subsets of this list." The aspects he names: "encapsulation", "protection", "ad hoc polymorphism", "parametric polymorphism", "everything is an object", "all you can do is send a message", "specification inheritance = subtyping", "implementation inheritance/reuse", "sum-of-product-of-function pattern". http://www.paulgraham.com/reesoo.html http://www.paulgraham.com/reesoo.html

MisterTea 3y ago

> Apparently oop as envisioned by Alan Kay was supposed to work like cells in the body that pass messages between each other and take actions independently. When I think of programs I think of modules of code that act like machines on a conveyor belt or assembly line operating on and pushing data along from station to station. This is why Erlang, Go and Plan 9's thread(2) library are how I want to program. > To the degree Erlang and Actors work, I think that's kind of a happy coincidence, and not due to any rigorous work on Alan Kay's part. https://www.infoq.com/interviews/johnson-armstrong-oop/ https://www.infoq.com/interviews/johnson-armstrong-oop/ (3. Is Erlang object oriented?) three points: message passing, isolation between objects, and polymorphism. The industry seems to have ran away with #3 while ignoring #2 and forgetting completely about #1.

CyberDildonics 3y ago
What you are describing is what a directed acyclic graph achieves. It works well when you need to do a series of transformations. It does not work well when you need branching, loops and state at a high level. The mistake people make is that they see it work very well for certain parts of their software, then they give in to silver bullet syndrome and try to make it work for everything.

igouy 3y ago

> Apparently oop as envisioned by Alan Kay was supposed to work like cells in the body that pass messages between each other and take actions independently. > Why? Who knows! It was never really explained… Perhaps "Design Principles Behind Smalltalk" ? https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk....

c_crank 3y ago

>Let alone that the entrenched, canonical, idiomatic coding styles of most modern oop languages encourage state, mutability, nulls, exceptions and god knows how many trivially preventable entire classes of errors. Granted, most have now started to come around and are adopting more fp features and ideas every year, but still. State isn't a feature solely of OOP. It's very easy to see the FP craze as a similarly dogmatic insistence on pure everything as removing useful features instead of preventing errors. If FP truly was the indisputable way of the future, Scala would be the CRUDspeak of choice by now.

Fire-Dragon-DoL 3y ago
Elixir has opt-in state that works really well! Everything immutable until you need state.

AtlasBarfed 3y ago

Most oop was designed in the context of desktop gui apps, which are much more complex that web apps imo. Is-a vs has-a is a lot more clear in context of widgets and windows. It still isn't perfect, most popular gii used inheritance whereas composition would probably be better. Inheritance ended up as a core component of oop principles when ultimately it is a flawed approach compared to more flexible composition methods. Liskov substitution was a massive success, classes were an improvement over structs, private vs public was generally a good idea even if the astro architects went nuts with it.

friendzis 3y ago

> And before anyone goes and comments aksully code organization blabla I'll bite. Having worked on "enterprise" application the OOP (or more like the dreaded enterprise patterns) have sort of "clicked" to me. An aside. Git-flow is more than decade old at this point and people still have heated debates from time to time on whether that approach is any good. In essence git-flow merely introduces organization to patchsets. If you are building a SaaS like system, most probably every environment you have runs "current" code and each stage (prod, test, dev) is merely a shifted pointer that will eventually catch up. Why would you structure your teamwork around identifiable patchsets, why would you keep that information around when you do trunk-based development? There is seemingly no need to do that and you would rightfully diss on git-flow as overly complex. However, if you build hardware appliances or installable offline application with multiple versions (think e.g. MS Office in 2000-2010 - multiple versions and tiers of those out in the wild under support), suddenly there are situations where you do in fact need to checkout and work on an exact patchset that is installed at customer site. If your field requires any form of certification, you will quickly learn that having patchsets provably not touching frozen (already certified or submitted for certification) code is highly valuable. Ability to cherry-pick a hotfix can save organization man-months. Back to code organization. So you have this "enterprise" application that has various software modules/components, some of which are built by external contractors, some are off-the-shelf components, some have been left and forgotten five years ago and for one reason or another you want to work on one of these components. Whatever team you assemble, majority will have zero understanding of assumptions baked into code. Documentation, however meticulously maintained, will still leave holes in understanding. How do you make changes to a decade old component that is used in various weird ways all throughout the project with any amount of confidence that you are not breaking stuff at a distance? Apparently, OOP enterprise patterns that introduce decoupling points for implementation details and pass around objects with assumptions abstracted away are pretty solid barriers. They are cumbersome, difficult to use at early stages of development when all complexity of the task can fit into the heads of programmers implementing features. Similarly to git-flow, the advantages of these structures only become apparent when you start needing them and that will quite probably be when the principal engineers greenfielding the project have long left the company altogether. A very specific example: factory pattern. Why would you have a layer of indirection to simply instantiate an object? All refcounting shenanigans aside, you just cannot change interface of object/component without affecting call sites. Call sites that may be outside of your control, code frozen or simply too dreadful to touch without strong justification. Factory pattern introduces a decoupling point between call sites and implementation. Having a factory you can implement interface shims and leave call sites untouched while having the freedom to rework component and its interface. You just cannot achieve that without OOP. > Let alone that the entrenched, canonical, idiomatic coding styles of most modern oop languages encourage state, mutability, nulls, exceptions and god knows how many trivially preventable entire classes of errors. I will agree that OOP implementations in mainstream languages leave much to be desired. That is part of the price we pay for backwards compatibility.