7 ms·

Every objects-first codebase I've seen was terrible. OOP survived mostly because people push hard for it, because they think there must be value in overly taxon

Every objects-first codebase I've seen was terrible. OOP survived mostly because people push hard for it, because they think there must be value in overly taxonomic code, but in the end they never seem to get value out of it, only more and more incompatible objects (when I hear "mock object" it's time to run). In OOP >50% of the LOC is just stupid bureaucrazy, setting up object graphs in the name of "isolation" (the irony), half-initializing fields, conforming to the right interfaces etc. This is completely meaningless, do-nothing code. Worse, it gives the illusion to remove some contextual dependencies this way, but the code never seems to work outside of the context it was created in. It's only much harder to read because the context is files away. OOP is the wrong-minded idea that a program should be a bundle of many "self-contained" objects. But that's wrong, we're writing ONE program here, not thousands. It tries to repair this wrong idea with inheritance (which is at least as bad an idea). And it makes it really hard to cope for "cross-cutting concerns", which are actually 90% of all we care for, not just a side concern. The complexity is in the edges (i.e. how is information moved/transformed), not in the objects! OOP mostly survived where performance / architectural scalability is not super important (e.g. Python or similar scripting languages, where it enables dynamic typing). And it survived where the big money is, but not necessarily technical competence (where it enables Object-verb type code completion). That relates to OOP as in languages like Java - not Alan Kay's idea of OOP, which he emphasizes was very different, but I still don't get what's the idea :p > A large majority of the code running on our planet today is OOP. Good example code base? > It's pretty much the only software paradigm that's survived for that long. Maybe check on your history? Many people are totally happy with procedural programming.

mgummelt 9y ago
> when I hear "mock object" it's time to run Do Haskell programmers not create mocks to test external components? > OOP is the wrong-minded idea that a program should be a bundle of many "self-contained" objects. But that's wrong, we're writing ONE program here, not thousands. The number of programs isn't the relevant metric. Complexity is. Any complex system is going to trend toward modularity. Modularity requires standard interfaces, which inevitably lead to bureaucracy. A 1MM line Haskell program is going to be similarly bureaucratic. There are going to be standards you have to adhere to in order to play nice with the rest of the system. That's what typeclasses are, after all. OOP is traditionally defined by three things: polymorphism, encapsulation, and inheritance. Polymorphism: Modern Non-OOP languages can also be polymorphic, so that's no longer a differentiator. Encapsulation: You definitely want encapsulation if your data is mutable. Inheritance: This is the only truly problematic feature, and it's certainly abused, but it has its place. I don't always want to compose and delegate 20 methods when I just want to change the behavior of one.
- tathougies 9y ago
  > Polymorphism: Modern Non-OOP languages can also be polymorphic, so that's no longer a differentiator. Haskell had ad-hoc polymorphism way before Java was a twinkle in its creator's eye. Before Haskell, Miranda (the language Haskell was based off of) could have kicked Java's polymorphism to the curb. Neither Java nor OOP invented polymorphism. If anything, they butchered it by introducing subtyping. > Do Haskell programmers not create mocks to test external components? The equivalent in Haskell would be having some kind of 'effects' system. An effect system differs from a mock object in that it limits in its totality what kind of interactions can take place. Typically, each layered effect also has a set of laws. Pure interpreters can be written for these effects, but the impure (i.e., real-world) interpreters are not privileged in their consumption of this effect. The pure interpreter also provides a proper implementation, such that you should be able to replace your real program with all pure interpreters, supply all your input at once, and still have a correct program. In other words, a Haskell program is typically polymorphic over which effects it uses in a way that other languages simply aren't. > Encapsulation: You definitely want encapsulation if your data is mutable. Again, Haskell, Miranda, and Lisp had encapsulation long before OOP came about, and Lisp has mutable data.
  - mgummelt 9y ago
    I think we're in violent agreement here. AFAICT, the feature sets of OOP and non-OOP languages have converged so much that inheritance is really the last differentiator. Maybe you could throw dynamic dispatch in there, but there's no reason in principle an OOP language couldn't add dynamic dispatch.
    - macintux 9y ago
      Mutability is a huge differentiator for some languages. And dynamic dispatch is already part of Smalltalk and Objective-C, I believe.
      - mgummelt 9y ago
        Sure, but mutability is orthogonal to OOP.
pbourke 9y ago
>> A large majority of the code running on our planet today is OOP. >Good example code base? The majority of code running Amazon the retail site and AWS. Large swathes of Microsoft and Google online services. Most code running bank back office and many trading systems. Likely 90%+ of the line of business applications run by the Fortune 500. Most desktop GUI programs. Should I keep going?
- nightski 9y ago
  But was that because of OOP? Or in spite of it? There are many reasons OOP is used in all of these systems which aren't related to it's technical "superiority". If popularity is a valuable metric, then javascript is probably the greatest language ever invented (sigh).
jeffreygoesto 9y ago
Can I please upvote this 100x? The "is-a" relationship is so much encapsulation gone wrong. Trying to encapsulate functionality in an object can not represent the multitude of things you want to do with them. Yet an amazing number of even CS grads religiously repeats OOP pattern.
mikekchar 9y ago
> That relates to OOP as in languages like Java - not Alan Kay's idea of OOP, which he emphasizes was very different, but I still don't get what's the idea It's bad of me to react to a single poster because I've seen many similar well reasoned arguments about why OOP is bad, but refer to something I would not call OOP -- I would just call it bad programming. To put it on it's head, there is a lot of terrible code out there. I wouldn't say that code whose authors believe it is OO is measurably worse than any other code I see. What I agree with is that it also isn't any better (which is often a surprise to those authors). I've seen some good OO code. I've seen some good procedural code. I've seen some good functional code. I've seen some good declarative code. But I've mostly seen terrible examples of all of them :-) One of the very unfortunate things that happened in the late 80's and 90's was the idea we should write self contained components that we would somehow plug and play all over the place. Despite the many, many horrible systems we wrote like that, the idea refuses to die. Some people believe that this is OO. They are wrong :-) We have exactly the same problem with "unit testing". Some people mistakenly believe that a "unit" is a piece of code taken in isolation. Then they think, "Hey... it's isolated... what else is isolated? Oh yeah! Objects!" So an object becomes a "unit" and it's tested in isolation... How do I isolate it? Oh yeah! I'll make fake objects for it to talk to. Yeah, it's a tyre fire. But even though it is popular and even though it is popularly called OO, I think it's a bit unfair. It would be like saying, functions are procedures that return values so the only difference between functional programming and procedural programming is that you always have to return a value. Yeah, it's super wrong, but it's so simple that you could convince a whole bunch of people it's true and then complain about how useless FP is. I realise that you realise that Alan Kay's idea of OOP is different, but the key part is "I still don't get what's the idea". When you find out, it would be nice to find out your reaction. Otherwise it's really just a strawman rant about how terrible mainstream programmers are (and we are.. terrible, that is ;-) ).
- jstimpfle 9y ago
  No, not a strawman at all. It's a rant about what bad qualities come from commonly accepted methodologies that fall under "OO". If you think that's not the common understanding of OO, you should state what you think it stands for instead and why you think it's still a good idea. You didn't do that. And pretty much nobody really understands what exactly is Alan Kay's vision, simply because it's rather vague and somewhat removed from practical reality. He seems to want "extreme late binding" (which need not be bad) and asynchronicity (Actor Model? can remove control and thus be problematic). He also has some vague idea of extreme parallelism that seems just very far removed from computational reality today. I think it's more a philosophical idea of how the physical and biological world could be seen as concurrent processes. I don't want to say his are bad ideas, and he is obviously an extremely intelligent and educated guy, but at the same time he also does not seem like an experienced programmer from a practical standpoint - but more of a visionary. So that's my idea, and if you have a different one, feel free to head over to the C2 wiki to convince yourself that most people don't really know what he means.
coldtea 9y ago
>> A large majority of the code running on our planet today is OOP. > Good example code base? It would be easier to give examples of non-OOP crucial programs, for they are far less. OOP codebases: -- Almost all major AAA games. -- Almost all GUI systems. -- All major browsers. -- Almost all video editors (NLE), -- Almost all audio DAWs -- All of Adobe's Suite -- Almost all 3D and CAD tools -- All office suites (MS Office, OpenOffice, iWork), -- All major IDEs (Visual Studio, IntelliJ, XCode, Eclipse) -- Most of Windows and OSX standard libraries -- Clang (and GCC now that they went to C++? Not sure if they use OOP) -- the JVM need we go on?
- jstimpfle 9y ago
  > OOP codebases: -- Almost all major AAA games. Nah. As far as I hear, most of them moved away from OOP a long time ago. "Component systems" have been hot for more than five years. > Almost all GUI systems Come on, what a GUI does vs a non-GUI "realtime" app is pretty trivial. A bit of layouting, routing a few input events. I'm not saying that e.g. building a scene graph or box model would be the wrong thing (there are other ways as well), but yeah... I certainly don't think that inheritance makes GUIs easier. Interfaces/Function pointers/dynamic dispatch? Yes, you might want that for decoupling a few containers of heterogeneous data/behaviour. But that's hardly a monopoly of "OOP", and also you don't need that in most places. The other projects, don't know them. Again, I'm not against abstractions per se (the Stream abstraction is one I regular use, although it does require unwrapping for proper error handling. And I have a constant number of "objects" in each of my programs, namely modules with global data). But OOP culture, especially objects-first mentality and fine-grained data encapsulation, gluing implementation to pristine data - I believe it does only harm and leads to plain wrong program structure and overcomplicated code to jump into all these boxes. I prefer gliding through arrays :-)
  - coldtea 9y ago
    >Nah. As far as I hear, most of them moved away from OOP a long time ago. "Component systems" have been hot for more than five years. Nope, that's just hype. Good ole C++ still rules the day, except for specialized (and smaller in scope and speed needs) games. >Come on, what a GUI does vs a non-GUI "realtime" app is pretty trivial. You'd be surprised. A guy is not just "call x program with some flags" as you might believe. Something like a NLE editor for example or even an IDE can have GUI needs that go far beyond hundreds of thousands of LOC... (Not to mention that I was referring to GUI libraries themselves, complex beasts on their own, not GUI code as used by applications to build their GUIs).
Volt 9y ago
> Every objects-first codebase I've seen was terrible. Does this include Smalltalk and CLOS codebases?
- jstimpfle 9y ago
  No. I don't know these languages but color me sceptical.
  - flavio81 9y ago
    you should take a good look at CLOS, you'll be colored rainbow-happy instead.
kybernetikos 9y ago
> Alan Kay's idea of OOP, which he emphasizes was very different, but I still don't get what's the idea :p I think his idea of OOP is something very close to what we call actors these days. It's a fractal design where it's 'computers' / objects communicating with messages all the way down.

mgummelt 9y ago

> when I hear "mock object" it's time to run Do Haskell programmers not create mocks to test external components? > OOP is the wrong-minded idea that a program should be a bundle of many "self-contained" objects. But that's wrong, we're writing ONE program here, not thousands. The number of programs isn't the relevant metric. Complexity is. Any complex system is going to trend toward modularity. Modularity requires standard interfaces, which inevitably lead to bureaucracy. A 1MM line Haskell program is going to be similarly bureaucratic. There are going to be standards you have to adhere to in order to play nice with the rest of the system. That's what typeclasses are, after all. OOP is traditionally defined by three things: polymorphism, encapsulation, and inheritance. Polymorphism: Modern Non-OOP languages can also be polymorphic, so that's no longer a differentiator. Encapsulation: You definitely want encapsulation if your data is mutable. Inheritance: This is the only truly problematic feature, and it's certainly abused, but it has its place. I don't always want to compose and delegate 20 methods when I just want to change the behavior of one.

tathougies 9y ago
> Polymorphism: Modern Non-OOP languages can also be polymorphic, so that's no longer a differentiator. Haskell had ad-hoc polymorphism way before Java was a twinkle in its creator's eye. Before Haskell, Miranda (the language Haskell was based off of) could have kicked Java's polymorphism to the curb. Neither Java nor OOP invented polymorphism. If anything, they butchered it by introducing subtyping. > Do Haskell programmers not create mocks to test external components? The equivalent in Haskell would be having some kind of 'effects' system. An effect system differs from a mock object in that it limits in its totality what kind of interactions can take place. Typically, each layered effect also has a set of laws. Pure interpreters can be written for these effects, but the impure (i.e., real-world) interpreters are not privileged in their consumption of this effect. The pure interpreter also provides a proper implementation, such that you should be able to replace your real program with all pure interpreters, supply all your input at once, and still have a correct program. In other words, a Haskell program is typically polymorphic over which effects it uses in a way that other languages simply aren't. > Encapsulation: You definitely want encapsulation if your data is mutable. Again, Haskell, Miranda, and Lisp had encapsulation long before OOP came about, and Lisp has mutable data.
- mgummelt 9y ago
  I think we're in violent agreement here. AFAICT, the feature sets of OOP and non-OOP languages have converged so much that inheritance is really the last differentiator. Maybe you could throw dynamic dispatch in there, but there's no reason in principle an OOP language couldn't add dynamic dispatch.
  - macintux 9y ago
    Mutability is a huge differentiator for some languages. And dynamic dispatch is already part of Smalltalk and Objective-C, I believe.
    - mgummelt 9y ago
      Sure, but mutability is orthogonal to OOP.

pbourke 9y ago

>> A large majority of the code running on our planet today is OOP. >Good example code base? The majority of code running Amazon the retail site and AWS. Large swathes of Microsoft and Google online services. Most code running bank back office and many trading systems. Likely 90%+ of the line of business applications run by the Fortune 500. Most desktop GUI programs. Should I keep going?

nightski 9y ago
But was that because of OOP? Or in spite of it? There are many reasons OOP is used in all of these systems which aren't related to it's technical "superiority". If popularity is a valuable metric, then javascript is probably the greatest language ever invented (sigh).

jeffreygoesto 9y ago

Can I please upvote this 100x? The "is-a" relationship is so much encapsulation gone wrong. Trying to encapsulate functionality in an object can not represent the multitude of things you want to do with them. Yet an amazing number of even CS grads religiously repeats OOP pattern.

mikekchar 9y ago

> That relates to OOP as in languages like Java - not Alan Kay's idea of OOP, which he emphasizes was very different, but I still don't get what's the idea It's bad of me to react to a single poster because I've seen many similar well reasoned arguments about why OOP is bad, but refer to something I would not call OOP -- I would just call it bad programming. To put it on it's head, there is a lot of terrible code out there. I wouldn't say that code whose authors believe it is OO is measurably worse than any other code I see. What I agree with is that it also isn't any better (which is often a surprise to those authors). I've seen some good OO code. I've seen some good procedural code. I've seen some good functional code. I've seen some good declarative code. But I've mostly seen terrible examples of all of them :-) One of the very unfortunate things that happened in the late 80's and 90's was the idea we should write self contained components that we would somehow plug and play all over the place. Despite the many, many horrible systems we wrote like that, the idea refuses to die. Some people believe that this is OO. They are wrong :-) We have exactly the same problem with "unit testing". Some people mistakenly believe that a "unit" is a piece of code taken in isolation. Then they think, "Hey... it's isolated... what else is isolated? Oh yeah! Objects!" So an object becomes a "unit" and it's tested in isolation... How do I isolate it? Oh yeah! I'll make fake objects for it to talk to. Yeah, it's a tyre fire. But even though it is popular and even though it is popularly called OO, I think it's a bit unfair. It would be like saying, functions are procedures that return values so the only difference between functional programming and procedural programming is that you always have to return a value. Yeah, it's super wrong, but it's so simple that you could convince a whole bunch of people it's true and then complain about how useless FP is. I realise that you realise that Alan Kay's idea of OOP is different, but the key part is "I still don't get what's the idea". When you find out, it would be nice to find out your reaction. Otherwise it's really just a strawman rant about how terrible mainstream programmers are (and we are.. terrible, that is ;-) ).

jstimpfle 9y ago
No, not a strawman at all. It's a rant about what bad qualities come from commonly accepted methodologies that fall under "OO". If you think that's not the common understanding of OO, you should state what you think it stands for instead and why you think it's still a good idea. You didn't do that. And pretty much nobody really understands what exactly is Alan Kay's vision, simply because it's rather vague and somewhat removed from practical reality. He seems to want "extreme late binding" (which need not be bad) and asynchronicity (Actor Model? can remove control and thus be problematic). He also has some vague idea of extreme parallelism that seems just very far removed from computational reality today. I think it's more a philosophical idea of how the physical and biological world could be seen as concurrent processes. I don't want to say his are bad ideas, and he is obviously an extremely intelligent and educated guy, but at the same time he also does not seem like an experienced programmer from a practical standpoint - but more of a visionary. So that's my idea, and if you have a different one, feel free to head over to the C2 wiki to convince yourself that most people don't really know what he means.

coldtea 9y ago

>> A large majority of the code running on our planet today is OOP. > Good example code base? It would be easier to give examples of non-OOP crucial programs, for they are far less. OOP codebases: -- Almost all major AAA games. -- Almost all GUI systems. -- All major browsers. -- Almost all video editors (NLE), -- Almost all audio DAWs -- All of Adobe's Suite -- Almost all 3D and CAD tools -- All office suites (MS Office, OpenOffice, iWork), -- All major IDEs (Visual Studio, IntelliJ, XCode, Eclipse) -- Most of Windows and OSX standard libraries -- Clang (and GCC now that they went to C++? Not sure if they use OOP) -- the JVM need we go on?

jstimpfle 9y ago
> OOP codebases: -- Almost all major AAA games. Nah. As far as I hear, most of them moved away from OOP a long time ago. "Component systems" have been hot for more than five years. > Almost all GUI systems Come on, what a GUI does vs a non-GUI "realtime" app is pretty trivial. A bit of layouting, routing a few input events. I'm not saying that e.g. building a scene graph or box model would be the wrong thing (there are other ways as well), but yeah... I certainly don't think that inheritance makes GUIs easier. Interfaces/Function pointers/dynamic dispatch? Yes, you might want that for decoupling a few containers of heterogeneous data/behaviour. But that's hardly a monopoly of "OOP", and also you don't need that in most places. The other projects, don't know them. Again, I'm not against abstractions per se (the Stream abstraction is one I regular use, although it does require unwrapping for proper error handling. And I have a constant number of "objects" in each of my programs, namely modules with global data). But OOP culture, especially objects-first mentality and fine-grained data encapsulation, gluing implementation to pristine data - I believe it does only harm and leads to plain wrong program structure and overcomplicated code to jump into all these boxes. I prefer gliding through arrays :-)
- coldtea 9y ago
  >Nah. As far as I hear, most of them moved away from OOP a long time ago. "Component systems" have been hot for more than five years. Nope, that's just hype. Good ole C++ still rules the day, except for specialized (and smaller in scope and speed needs) games. >Come on, what a GUI does vs a non-GUI "realtime" app is pretty trivial. You'd be surprised. A guy is not just "call x program with some flags" as you might believe. Something like a NLE editor for example or even an IDE can have GUI needs that go far beyond hundreds of thousands of LOC... (Not to mention that I was referring to GUI libraries themselves, complex beasts on their own, not GUI code as used by applications to build their GUIs).

Volt 9y ago

> Every objects-first codebase I've seen was terrible. Does this include Smalltalk and CLOS codebases?

jstimpfle 9y ago
No. I don't know these languages but color me sceptical.
- flavio81 9y ago
  you should take a good look at CLOS, you'll be colored rainbow-happy instead.

kybernetikos 9y ago

> Alan Kay's idea of OOP, which he emphasizes was very different, but I still don't get what's the idea :p I think his idea of OOP is something very close to what we call actors these days. It's a fractal design where it's 'computers' / objects communicating with messages all the way down.