Comment by anonymars
5 days 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.)
> 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.
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
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.