4 ms·

> Rust has straightforward support for every part of OOP other than implementation inheritance Except the only thing that makes OOP OOP: Message passing. Gran

by 9rx 8mo ago

> Rust has straightforward support for every part of OOP other than implementation inheritance Except the only thing that makes OOP OOP: Message passing. Granted, Swift only just barely supports it, and only for the sake of interop with Objective-C. Still, Swift has better OO support because of it. Rust doesn't even try. Not that OOP is much of a goal. There is likely good reason why Smalltalk, Objective-C, and Ruby are really the only OOP languages in existence (some esoteric language nobody has ever heard of notwithstanding).

zozbot234 8mo ago
You just need to define a trait, then you can use dynamic dispatch.
- 9rx 8mo ago
  You can, but then you don't get any of what OOP actually offers. Message passing isn't the same thing as dynamic dispatch. OOP is a very different paradigm.
  - anonymars 8mo ago
    I think you are both unknowingly talking past each other: my understanding is that Smalltalk-style "object-oriented programming" ("everything is a message!") is quite distinct from C++/C#/Java/Rust "object-oriented programming" ("my structs have methods!")
    - deleted 8mo ago
      [deleted]
    - 9rx 8mo ago
      Right, the former is what OOP is. The latter, encapsulating data in "objects", is functional programming.
      - anonymars 8mo ago
        They are both OOP, just as a "football" can be either spherical or oblong. Functional programming is not "encapsulating data in 'objects'". Such a model would naturally feature methods like "void Die.roll()", "void list.Add(element)" which are definitely not functional programming (which emphasizes immutability, pure functions, composition, etc.)
        9rx 8mo ago
        > They are both OOP, just as a "football" can be either spherical or oblong. They are both OOP like a football can be something that you use in a sport and something that flies you to the moon. Except it is not clear what flies you to the moon goes by "football". > Such a model would naturally feature methods like "void Die.roll()", "void list.Add(element)" which are definitely not functional programming Exactly, functional programming. `Die` and `list` encapsulate data and use higher order functions to operate on it, which is what defines functional programming. > which emphasizes [...] pure functions Functions without encapsulation is imperative programming. If you introduce encapsulation then, yes, you have functional programming, just like your examples above. Immutability is a disjoined property that can optionally apply to all of these programming paradigms. OOP, functional, and imperative programs can all be immutable, or not. Composition and encapsulation go hand in hand, so that one is also functional programming, yes. And certainly composition is core to languages like C++/Java/Rust/etc. Naturally, them being functional languages. To reiterate: - Imperative programming: Data and functions are separate. - Functional programming: Data is grouped with functions. - Object-oriented programming: Data is grouped with message responders.
        anonymars 8mo ago
        You're welcome to insist that your definitions are canonical ("the objective in football is to kick the ball into the net"), but they are at odds with the rest of the thread
        9rx 8mo ago
        Just as you are welcome to come up with other definitions. Although last time you tried they ended up being quite inconsistent, so one does need to be careful if you want them to be useful. These definitions are not at odds with the discussion at hand at all. It was clearly stated that Swift has better OO support. Which is obviously true because it tries to be compatible with Objective-C, and therefore needs to have some level of OO support. That is something that Rust has no interest in doing, and rightfully so. Your redefinition violates the claim, and therefore we can logically determine that it is not what was being used in the rest of the thread. That is, aside from the confused Rust guy that set this tangent in motion, but the remainder of this thread was merely clarifying to him what was originally intended. "He has a different definition for OOP" doesn't really help his understanding. That is what this thread branch has always been about, so it is not clear where you are trying to go with that.
three_burgers 8mo ago
I’m pretty sure when the Ladybird team said “Swift has strictly better OOP support”, they were not referring to ObjC style message passing, so it’s not even relevant.
- 9rx 8mo ago
  I'm pretty sure your guessing is silly. I assume you are trying to be here in good faith, so make your case. Since it is not support for message passing, what else makes Swift have "strictly better OOP support"?
  - refulgentis 8mo ago
    That's the thing man, there isn't anything. It was an odd thing in the tweet to say that it has better OOP. (source: iOS dev from jailbreak days, so like 8 years before Swift, till 2019. He did not mean dynamic dispatch and Swift has dynamic dispatch by way of "you can annotate a Swift method with @objc and we'll emit it as an ObjC method instead of Swift", not Smalltalk-ish, like, at all. if you're the poster who originally said "because of dynamic dispatch", I understand why you're frustrated but I have 0 idea why you think dynamic dispatch in Swift would matter, much less say it makes Swift much better at OOP than Rust. It's impolite to say "utterly baffling engineering decision" in public, so there's subtext in the conversation. Namely that both claims made 0 sense if you had practical familiarity with either)
    - 9rx 8mo ago
      > That's the thing man, there isn't anything. But that's the thing, there is: It supports message passing. Like we already discussed long ago, it supports it poorly, and only for the sake of compatibility with Objective-C, but still that makes its OOP support better than Rust's. Rust has no OOP support at all. It is not an OOP language and never would want to be. OOP goes completely against its core principles (statically-typed, performance-minded). Realistically, nobody would consider Swift an OOP language either. However, on the spectrum, it is unquestionably closer to being an OOP language. It at least gets an honourable mention in the short list of OOP languages. It is undeniable that Swift has "better" OOP support; not to be confused with good OOP support. > He did not mean dynamic dispatch Of course not. Dynamic dispatch is for function calling. OOP doesn't use dynamic dispatch. That's literally why we call it object-oriented rather than function-oriented (or functional, as the kids say). This is also why Objective-C, quite brilliantly, uses [foo bar] syntax (hint: it kind of looks like an ASCII-art envelope for a reason): To make it clear that conceptually you are not calling a function. > I understand why you're frustrated I don't. Fill us in.

by 9rx 8mo ago

zozbot234 8mo ago

You just need to define a trait, then you can use dynamic dispatch.

9rx 8mo ago
You can, but then you don't get any of what OOP actually offers. Message passing isn't the same thing as dynamic dispatch. OOP is a very different paradigm.
- anonymars 8mo ago
  I think you are both unknowingly talking past each other: my understanding is that Smalltalk-style "object-oriented programming" ("everything is a message!") is quite distinct from C++/C#/Java/Rust "object-oriented programming" ("my structs have methods!")
  - deleted 8mo ago
    [deleted]
  - 9rx 8mo ago
    Right, the former is what OOP is. The latter, encapsulating data in "objects", is functional programming.
    - anonymars 8mo ago
      They are both OOP, just as a "football" can be either spherical or oblong. Functional programming is not "encapsulating data in 'objects'". Such a model would naturally feature methods like "void Die.roll()", "void list.Add(element)" which are definitely not functional programming (which emphasizes immutability, pure functions, composition, etc.)
      - 9rx 8mo ago
        > They are both OOP, just as a "football" can be either spherical or oblong. They are both OOP like a football can be something that you use in a sport and something that flies you to the moon. Except it is not clear what flies you to the moon goes by "football". > Such a model would naturally feature methods like "void Die.roll()", "void list.Add(element)" which are definitely not functional programming Exactly, functional programming. `Die` and `list` encapsulate data and use higher order functions to operate on it, which is what defines functional programming. > which emphasizes [...] pure functions Functions without encapsulation is imperative programming. If you introduce encapsulation then, yes, you have functional programming, just like your examples above. Immutability is a disjoined property that can optionally apply to all of these programming paradigms. OOP, functional, and imperative programs can all be immutable, or not. Composition and encapsulation go hand in hand, so that one is also functional programming, yes. And certainly composition is core to languages like C++/Java/Rust/etc. Naturally, them being functional languages. To reiterate: - Imperative programming: Data and functions are separate. - Functional programming: Data is grouped with functions. - Object-oriented programming: Data is grouped with message responders.
        anonymars 8mo ago
        You're welcome to insist that your definitions are canonical ("the objective in football is to kick the ball into the net"), but they are at odds with the rest of the thread
        9rx 8mo ago
        Just as you are welcome to come up with other definitions. Although last time you tried they ended up being quite inconsistent, so one does need to be careful if you want them to be useful. These definitions are not at odds with the discussion at hand at all. It was clearly stated that Swift has better OO support. Which is obviously true because it tries to be compatible with Objective-C, and therefore needs to have some level of OO support. That is something that Rust has no interest in doing, and rightfully so. Your redefinition violates the claim, and therefore we can logically determine that it is not what was being used in the rest of the thread. That is, aside from the confused Rust guy that set this tangent in motion, but the remainder of this thread was merely clarifying to him what was originally intended. "He has a different definition for OOP" doesn't really help his understanding. That is what this thread branch has always been about, so it is not clear where you are trying to go with that.

three_burgers 8mo ago

I’m pretty sure when the Ladybird team said “Swift has strictly better OOP support”, they were not referring to ObjC style message passing, so it’s not even relevant.

9rx 8mo ago
I'm pretty sure your guessing is silly. I assume you are trying to be here in good faith, so make your case. Since it is not support for message passing, what else makes Swift have "strictly better OOP support"?
- refulgentis 8mo ago
  That's the thing man, there isn't anything. It was an odd thing in the tweet to say that it has better OOP. (source: iOS dev from jailbreak days, so like 8 years before Swift, till 2019. He did not mean dynamic dispatch and Swift has dynamic dispatch by way of "you can annotate a Swift method with @objc and we'll emit it as an ObjC method instead of Swift", not Smalltalk-ish, like, at all. if you're the poster who originally said "because of dynamic dispatch", I understand why you're frustrated but I have 0 idea why you think dynamic dispatch in Swift would matter, much less say it makes Swift much better at OOP than Rust. It's impolite to say "utterly baffling engineering decision" in public, so there's subtext in the conversation. Namely that both claims made 0 sense if you had practical familiarity with either)
  - 9rx 8mo ago
    > That's the thing man, there isn't anything. But that's the thing, there is: It supports message passing. Like we already discussed long ago, it supports it poorly, and only for the sake of compatibility with Objective-C, but still that makes its OOP support better than Rust's. Rust has no OOP support at all. It is not an OOP language and never would want to be. OOP goes completely against its core principles (statically-typed, performance-minded). Realistically, nobody would consider Swift an OOP language either. However, on the spectrum, it is unquestionably closer to being an OOP language. It at least gets an honourable mention in the short list of OOP languages. It is undeniable that Swift has "better" OOP support; not to be confused with good OOP support. > He did not mean dynamic dispatch Of course not. Dynamic dispatch is for function calling. OOP doesn't use dynamic dispatch. That's literally why we call it object-oriented rather than function-oriented (or functional, as the kids say). This is also why Objective-C, quite brilliantly, uses [foo bar] syntax (hint: it kind of looks like an ASCII-art envelope for a reason): To make it clear that conceptually you are not calling a function. > I understand why you're frustrated I don't. Fill us in.