3 ms·

Programming is mostly about understanding the problem domain. It is interesting that OOP had its heydey when everyone was building native GUI programs. The most

by roenxi 3y ago

Programming is mostly about understanding the problem domain. It is interesting that OOP had its heydey when everyone was building native GUI programs. The most likely situation was that programmers were developing abstractions that matched well to GUIs and those abstractions most closely mapped to OOP. Things like functional programming, OOP, declarative programming, etc, might matter to language designers. They need these concepts to work out if their language is convenient/internally consistent/featureful and maybe these banner concepts help. Once the language has been built, I don't think programmers actually care. The abstraction isn't at the sweet spot where a developer gets the most power. The components of OOP (encapsulation, message passing, interfaces) are important and should be used liberally - but grouping them together under one heading is detrimental, because there will also be opportunities for other techniques from other schools of thought. And as an aside inheritance seems to have been a mistake. I haven't seen a lot of places where inheritance was the best idea. Interfaces yes, inheritance no.

dventimihasura 3y ago
> The most likely situation was that programmers were developing abstractions that matched well to GUIs and those abstractions most closely mapped to OOP. Bingo
- randomdata 3y ago
  Questionable. Qt signal/slot extensions were undeniably created to add OOP concepts to C++ for the sake of GUIs. You might, if you stretch hard enough, be able to make a case that Objective-C emerged for the sake of GUIs. But what else beyond that? Smalltalk most definitely influenced how we thought about GUIs, but never really solidified itself as the place to develop GUIs. Class-based, non-OOP, languages seemed to be where most GUI development happened. And in large part were suited to the task. There was little need to introduce OOP. There was COM and the like, which perhaps can reasonably be considered object-oriented, but only at a higher level of abstraction. The programming was not object-oriented. OO, but not OOP.
  - dventimihasura 3y ago
    You're free to use your own private definition of OOP, but nobody else is obliged to join you.
    - randomdata 3y ago
      Agreed. Which is why we are sticking to the definition as has been already defined. Anything else, while perhaps interesting for a completely different discussion, would be clearly off-topic for this one.
      - dventimihasura 3y ago
        > Which is why we are sticking to the definition as has been already defined. Has already been defined where exactly? Yes, evidently you believe it has been defined in the article, but where exactly in the article did that occur. Please be precise.
        randomdata 3y ago
        First thing you read. That's where definitions go. Obviously you are not going to go on at length about something and then "Oh yeah, and by the way, this is what I meant by X. Gotcha!" Of course it is going to be the first thing you read.
        dventimihasura 3y ago
        > First thing you read. That's where definitions go. Says who? You? Did you get a confirmation from the article author that this was their intention? After all, the first thing you read in the article is a quote, but then there's a second quote later from a different person, which doesn't specifically address the first quote. Is that also a definition? No, in reality, you don't know the author's definition. Neither of us does, which is why we have to make an educated guess (an "inference"). You've guessed evidently that the author's definition is identical to Kay's. Well, let's consider your confidence around that guess. When the author discusses other topics not included in that definition, like inheritance and polymorphism, does that tend to increase or decrease your confidence in your guess? Finally, just as I'm not obliged to use your definition and you're not obliged to use mine, neither of us is obliged to use the blog article author's definition either. I certainly didn't agree to that, and there's good reason not to, which is that there are other people involved: the OOP critics. The article author accuses OOP critics of not understanding OOP. Personally, I think that gives us a reason to use THEIR definition of OOP, not the author's. That is, unless the author's argument "they don't understand OOP" is essentially "they're using the wrong definition of OOP." But then, since there is no right or wrong definition of OOP, that could only mean, "they're using a different definition of OOP from the one I'm using", which they're free to do. To sum up, your argument essentially is, "you critics of OOP are not using the definition that I use." OK. Well, who asked you?
randomdata 3y ago
> It is interesting that OOP had its heydey when everyone was building native GUI programs. Erlang is probably the only OOP language in existence. I'm not sure it was ever the tool of choice for GUIs.
magicalhippo 3y ago
> I haven't seen a lot of places where inheritance was the best idea. Interfaces yes, inheritance no. I like to use interfaces to expose the public side of things, but I find inheritance can be really powerful in terms of code-reuse for implementing those interfaces. Of course if you got a language that makes encapsulation very smooth then inheritance might not be needed, but otherwise I find it can really cut down on code re-use and boilerplate to have a base class for certain interfaces. Of course, since the interface is the public bit, if the base class is not a good fit for a certain implementation there's no requirement to use the common base class. So you use it when it makes sense.

by roenxi 3y ago

dventimihasura 3y ago

> The most likely situation was that programmers were developing abstractions that matched well to GUIs and those abstractions most closely mapped to OOP. Bingo

randomdata 3y ago
Questionable. Qt signal/slot extensions were undeniably created to add OOP concepts to C++ for the sake of GUIs. You might, if you stretch hard enough, be able to make a case that Objective-C emerged for the sake of GUIs. But what else beyond that? Smalltalk most definitely influenced how we thought about GUIs, but never really solidified itself as the place to develop GUIs. Class-based, non-OOP, languages seemed to be where most GUI development happened. And in large part were suited to the task. There was little need to introduce OOP. There was COM and the like, which perhaps can reasonably be considered object-oriented, but only at a higher level of abstraction. The programming was not object-oriented. OO, but not OOP.
- dventimihasura 3y ago
  You're free to use your own private definition of OOP, but nobody else is obliged to join you.
  - randomdata 3y ago
    Agreed. Which is why we are sticking to the definition as has been already defined. Anything else, while perhaps interesting for a completely different discussion, would be clearly off-topic for this one.
    - dventimihasura 3y ago
      > Which is why we are sticking to the definition as has been already defined. Has already been defined where exactly? Yes, evidently you believe it has been defined in the article, but where exactly in the article did that occur. Please be precise.
      - randomdata 3y ago
        First thing you read. That's where definitions go. Obviously you are not going to go on at length about something and then "Oh yeah, and by the way, this is what I meant by X. Gotcha!" Of course it is going to be the first thing you read.
        dventimihasura 3y ago
        > First thing you read. That's where definitions go. Says who? You? Did you get a confirmation from the article author that this was their intention? After all, the first thing you read in the article is a quote, but then there's a second quote later from a different person, which doesn't specifically address the first quote. Is that also a definition? No, in reality, you don't know the author's definition. Neither of us does, which is why we have to make an educated guess (an "inference"). You've guessed evidently that the author's definition is identical to Kay's. Well, let's consider your confidence around that guess. When the author discusses other topics not included in that definition, like inheritance and polymorphism, does that tend to increase or decrease your confidence in your guess? Finally, just as I'm not obliged to use your definition and you're not obliged to use mine, neither of us is obliged to use the blog article author's definition either. I certainly didn't agree to that, and there's good reason not to, which is that there are other people involved: the OOP critics. The article author accuses OOP critics of not understanding OOP. Personally, I think that gives us a reason to use THEIR definition of OOP, not the author's. That is, unless the author's argument "they don't understand OOP" is essentially "they're using the wrong definition of OOP." But then, since there is no right or wrong definition of OOP, that could only mean, "they're using a different definition of OOP from the one I'm using", which they're free to do. To sum up, your argument essentially is, "you critics of OOP are not using the definition that I use." OK. Well, who asked you?

randomdata 3y ago

> It is interesting that OOP had its heydey when everyone was building native GUI programs. Erlang is probably the only OOP language in existence. I'm not sure it was ever the tool of choice for GUIs.

magicalhippo 3y ago

> I haven't seen a lot of places where inheritance was the best idea. Interfaces yes, inheritance no. I like to use interfaces to expose the public side of things, but I find inheritance can be really powerful in terms of code-reuse for implementing those interfaces. Of course if you got a language that makes encapsulation very smooth then inheritance might not be needed, but otherwise I find it can really cut down on code re-use and boilerplate to have a base class for certain interfaces. Of course, since the interface is the public bit, if the base class is not a good fit for a certain implementation there's no requirement to use the common base class. So you use it when it makes sense.