5 ms·

Hi, mediocre programmer here. OOP is the most popular paradigm because it works the best for the greatest number of people and projects. It's natural to break

Hi, mediocre programmer here. OOP is the most popular paradigm because it works the best for the greatest number of people and projects. It's natural to break large systems into component parts recursively, and to let components have their own state. What alternative did you have in mind? Functional programming?

TeMPOraL 9y ago
Breaking up a problem recursively into stateful components is completely orthogonal to OOP.
- thesmallestcat 9y ago
  As is coupling state and function. Parent's comment is a good demonstration of the inertia of misinformed adherence to OOP.
  - halter73 9y ago
    Since you seem confident that your understanding of OOP is better than that of "misinformed" people like me who don't think that coupling state and function is completely orthoganal OOP, can you explain what isn't completely orthoganal? A succinct definition of OOP would be nice to combat the misinformation you're complaining about. The description of OOP provided in the Wikipedia article on programming paradigms [1] matches my current understanding of OOP. > object-oriented which groups code together with the state the code modifies, Maybe that's a little too succinct, because I think it's also worth noting how [2] > In OOP, computer programs are designed by making them out of objects that interact with one another. I certainly wouldn't consider coupling state and function completely orthogonal to OOP though. I doubt most other programmers would either. I guess this might demonstrate the inertia of the so-called misinformation, but when the majority disagree with your definition of a term, you might want to step back and consider whether you're the one who's misinformed. [1] https://en.m.wikipedia.org/wiki/Programming_paradigm https://en.m.wikipedia.org/wiki/Programming_paradigm [2] https://en.m.wikipedia.org/wiki/Object-oriented_programming https://en.m.wikipedia.org/wiki/Object-oriented_programming
    - thesmallestcat 9y ago
      The fundamental ideas of OOP are pervasive data privacy and the consequent synchronization via message passing. Now, many OO languages have badly butchered that, but that is the idea, as in Smalltalk: Objects are opaque participants in a colloquy. I'm not sure where you got "the majority disagree with your definition of the term" when I didn't even attempt to define the term until this reply! Or why you key on the word "orthogonal" which is in the parent of my comment, and certainly is imprecise: A better description would be, OOP holds no exclusive claim to these ideas. We don't all despise OOP, but rather the false notion that it is a "silver bullet." I quite like well done OOP with expressive types. I'd be irritated by you linking to Wikipedia articles for "Programming paradigm" and OOP except they're mobile links, which means you're getting all in a hissy on the go, and that's sorta cute.
      - halter73 9y ago
        I probably put too much stock in the "As is" at the beginning of your post. A hissy is a good description of my last comment lol. I was getting pretty annoyed at people claiming that my understanding of OOP is wrong. I don't think OOP should be this incomprehensible thing. I now understand that you just meant that not all encapsulation is OOP. I certainly agree there. Cheers.
      - deleted 9y ago
        [deleted]
      - unscaled 9y ago
        OOP does not start with Smalltalk, but rather with Simula 67 a decade earlier. Simula 67 - not Smalltalk - was the main force that drove Bjarne Stroustrup to extend C into C++ and the rest history: While Smalltalk did enjoy a period of mild popularity in the late 80s early 90s and went on to influence other languages like Objective C and Ruby, the mainstream of OOP was defined by C++ and later Java. These languages viewed focused on statically determined method dispatch rather than message-passing, but this is a feature of their older lineage rather than the butchering of the original pristine form of OOP which never was.
    - coding123 9y ago
fizixer 9y ago
> What alternative did you have in mind? My favorite question. Have a look at the sidebar in this link [1] for starters (by 'alternative' you didn't mean you expect me to advocate complete abolishment of OOP did you?). I'd say being familiar with at least 5-10 diverse paradigms from that list works wonders. [1] https://en.wikipedia.org/wiki/Programming_paradigm https://en.wikipedia.org/wiki/Programming_paradigm
IncRnd 9y ago
The design principles of modularity and stateful components exist independent of an OOP.
whorleater 9y ago
> It's natural to break large systems into component parts recursively, and to let components have their own state The biggest lie OOP ever told was that breaking things into smaller components is specific to OOP
- deleted 9y ago
  [deleted]
- simonh 9y ago
  And now we're slinging obnoxious insulting mud. Lovely. Thank you for your contribution. I'm going to be that guy. Citation please, even one statement anywhere by an author if an OOP language or of a book on OOP where they say it's the only way to do that.
  - Tomis02 9y ago
    They don't have to say it, it's implied by omission. When OOP proponents keep repeating that it breaks a program into smaller, more manageable parts, it's easy for beginning programmers to assume that this is a defining feature of OOP and that it's somehow specific to it.
Pica_soO 9y ago
It depends- basically, the approach is to not think of OOP as the default approach, just one of the tools in the box. When you have a algorithm that goes Red-Hot, use Data-Orientated-Programming. When you have lots of annonymous objects repeatetly passing through recombined pipelines, with minimal work, try a functional approach. Try to see OOP not as the final stage of a masterpiece, rather as the launch-pad - and a first working version. Also- what is the best approach, highly depends upon the goals of the project. Speed at all cost? Safety trumps all? Rapid development? Scale-ability? PS: Regarding Object-Relational Databases- i found the true nest of snakes to be that for each object basically a small hand crafted version of git is needed to resolve the changes, once several applications start using the same DB. Not only that, but changes made, that relate to the changed data, needs to propagate- and can not do so only by simple trigger, but often by program-logic. Sloppy work can lead to data fragments being part of two separate objects. What if two programs use one of two classes, but one resides within the other? Who has the right of update? In addition ORM can hold duplicates of a Datum, and very soon, the urge will appear to replace every datafragment in your saved object with a pointer (key) to one, and only one instance of the real-world data piece. TL,DR; This is one of the cases, where the pain comes not instantly, but after a while - and then never leaves. Get somebody who witnessed something like that blow up in another company to help you avoiding the worst.
naasking 9y ago
> OOP is the most popular paradigm because it works the best for the greatest number of people and projects It's a novice mistake to think the solution that wins out is the one with the most technical merit. Virtually nothing is truly meritocratic. > It's natural to break large systems into component parts recursively, and to let components have their own state. That's just modularity. Nearly every language has it, and OOP is merely one way to achieve it.
- seanmcdirmid 9y ago
  What other paradigm focuses on components with encapsulated state? Definitely not functional! Isn't any nounish "thing" with state an object anyways? Why else could it be?
  - di4na 9y ago
    Because there are no "nounish" things. It is a false construct. Also see Actor model or "out of the tarpit". Also Barbara Liskov "Programming with Abstract Data Type". Encapsulating state instead of behaviours is a mistake.
    - seanmcdirmid 9y ago
      Hewitt never said actors weren't objects, quite the opposite actually. Heck, simula (the first OOP language) objects were very actor like. Grand parent is talking specifically about encapsulating state and not just behaviors.
      - di4na 9y ago
        Simula objects were not a Actor like, they were exactly like today object. Smalltalk originally was like Actors, and it is what spawned the idea in Hewitt mind. Our Objects of today come straight from Simula. Edit : and yes, there is a reason i said behaviour and not state. Objects are bad at encapsulating state, because you do not encapsulate state like that.

TeMPOraL 9y ago

Breaking up a problem recursively into stateful components is completely orthogonal to OOP.

thesmallestcat 9y ago
As is coupling state and function. Parent's comment is a good demonstration of the inertia of misinformed adherence to OOP.
- halter73 9y ago
  Since you seem confident that your understanding of OOP is better than that of "misinformed" people like me who don't think that coupling state and function is completely orthoganal OOP, can you explain what isn't completely orthoganal? A succinct definition of OOP would be nice to combat the misinformation you're complaining about. The description of OOP provided in the Wikipedia article on programming paradigms [1] matches my current understanding of OOP. > object-oriented which groups code together with the state the code modifies, Maybe that's a little too succinct, because I think it's also worth noting how [2] > In OOP, computer programs are designed by making them out of objects that interact with one another. I certainly wouldn't consider coupling state and function completely orthogonal to OOP though. I doubt most other programmers would either. I guess this might demonstrate the inertia of the so-called misinformation, but when the majority disagree with your definition of a term, you might want to step back and consider whether you're the one who's misinformed. [1] https://en.m.wikipedia.org/wiki/Programming_paradigm https://en.m.wikipedia.org/wiki/Programming_paradigm [2] https://en.m.wikipedia.org/wiki/Object-oriented_programming https://en.m.wikipedia.org/wiki/Object-oriented_programming
  - thesmallestcat 9y ago
    The fundamental ideas of OOP are pervasive data privacy and the consequent synchronization via message passing. Now, many OO languages have badly butchered that, but that is the idea, as in Smalltalk: Objects are opaque participants in a colloquy. I'm not sure where you got "the majority disagree with your definition of the term" when I didn't even attempt to define the term until this reply! Or why you key on the word "orthogonal" which is in the parent of my comment, and certainly is imprecise: A better description would be, OOP holds no exclusive claim to these ideas. We don't all despise OOP, but rather the false notion that it is a "silver bullet." I quite like well done OOP with expressive types. I'd be irritated by you linking to Wikipedia articles for "Programming paradigm" and OOP except they're mobile links, which means you're getting all in a hissy on the go, and that's sorta cute.
    - halter73 9y ago
      I probably put too much stock in the "As is" at the beginning of your post. A hissy is a good description of my last comment lol. I was getting pretty annoyed at people claiming that my understanding of OOP is wrong. I don't think OOP should be this incomprehensible thing. I now understand that you just meant that not all encapsulation is OOP. I certainly agree there. Cheers.
    - deleted 9y ago
      [deleted]
    - unscaled 9y ago
      OOP does not start with Smalltalk, but rather with Simula 67 a decade earlier. Simula 67 - not Smalltalk - was the main force that drove Bjarne Stroustrup to extend C into C++ and the rest history: While Smalltalk did enjoy a period of mild popularity in the late 80s early 90s and went on to influence other languages like Objective C and Ruby, the mainstream of OOP was defined by C++ and later Java. These languages viewed focused on statically determined method dispatch rather than message-passing, but this is a feature of their older lineage rather than the butchering of the original pristine form of OOP which never was.
  - coding123 9y ago

fizixer 9y ago

> What alternative did you have in mind? My favorite question. Have a look at the sidebar in this link [1] for starters (by 'alternative' you didn't mean you expect me to advocate complete abolishment of OOP did you?). I'd say being familiar with at least 5-10 diverse paradigms from that list works wonders. [1] https://en.wikipedia.org/wiki/Programming_paradigm https://en.wikipedia.org/wiki/Programming_paradigm

IncRnd 9y ago

The design principles of modularity and stateful components exist independent of an OOP.

whorleater 9y ago

> It's natural to break large systems into component parts recursively, and to let components have their own state The biggest lie OOP ever told was that breaking things into smaller components is specific to OOP

deleted 9y ago
[deleted]
simonh 9y ago
And now we're slinging obnoxious insulting mud. Lovely. Thank you for your contribution. I'm going to be that guy. Citation please, even one statement anywhere by an author if an OOP language or of a book on OOP where they say it's the only way to do that.
- Tomis02 9y ago
  They don't have to say it, it's implied by omission. When OOP proponents keep repeating that it breaks a program into smaller, more manageable parts, it's easy for beginning programmers to assume that this is a defining feature of OOP and that it's somehow specific to it.

Pica_soO 9y ago

It depends- basically, the approach is to not think of OOP as the default approach, just one of the tools in the box. When you have a algorithm that goes Red-Hot, use Data-Orientated-Programming. When you have lots of annonymous objects repeatetly passing through recombined pipelines, with minimal work, try a functional approach. Try to see OOP not as the final stage of a masterpiece, rather as the launch-pad - and a first working version. Also- what is the best approach, highly depends upon the goals of the project. Speed at all cost? Safety trumps all? Rapid development? Scale-ability? PS: Regarding Object-Relational Databases- i found the true nest of snakes to be that for each object basically a small hand crafted version of git is needed to resolve the changes, once several applications start using the same DB. Not only that, but changes made, that relate to the changed data, needs to propagate- and can not do so only by simple trigger, but often by program-logic. Sloppy work can lead to data fragments being part of two separate objects. What if two programs use one of two classes, but one resides within the other? Who has the right of update? In addition ORM can hold duplicates of a Datum, and very soon, the urge will appear to replace every datafragment in your saved object with a pointer (key) to one, and only one instance of the real-world data piece. TL,DR; This is one of the cases, where the pain comes not instantly, but after a while - and then never leaves. Get somebody who witnessed something like that blow up in another company to help you avoiding the worst.

naasking 9y ago

> OOP is the most popular paradigm because it works the best for the greatest number of people and projects It's a novice mistake to think the solution that wins out is the one with the most technical merit. Virtually nothing is truly meritocratic. > It's natural to break large systems into component parts recursively, and to let components have their own state. That's just modularity. Nearly every language has it, and OOP is merely one way to achieve it.

seanmcdirmid 9y ago
What other paradigm focuses on components with encapsulated state? Definitely not functional! Isn't any nounish "thing" with state an object anyways? Why else could it be?
- di4na 9y ago
  Because there are no "nounish" things. It is a false construct. Also see Actor model or "out of the tarpit". Also Barbara Liskov "Programming with Abstract Data Type". Encapsulating state instead of behaviours is a mistake.
  - seanmcdirmid 9y ago
    Hewitt never said actors weren't objects, quite the opposite actually. Heck, simula (the first OOP language) objects were very actor like. Grand parent is talking specifically about encapsulating state and not just behaviors.
    - di4na 9y ago
      Simula objects were not a Actor like, they were exactly like today object. Smalltalk originally was like Actors, and it is what spawned the idea in Hewitt mind. Our Objects of today come straight from Simula. Edit : and yes, there is a reason i said behaviour and not state. Objects are bad at encapsulating state, because you do not encapsulate state like that.