Comment by refulgentis
5 days ago
Ok, I've now read through the rest of this thread and I think I understand where you're coming from, but I also think you're making my point for me.
You're using a definition of OOP where only Smalltalk-style message passing counts. By that definition, you're right: Swift is closer, because `@objc` exists. But by that definition, neither Swift nor Rust is an OOP language in any meaningful sense, and the delta between them is mass-of-the-electron tiny. Swift's message passing support is an annotation that is a compatibility shim for a 40-year-old runtime, not a design philosophy.
So when you say Swift has "better OO support"... sure, in the same way that my car has better submarine support than yours because I left the windows cracked and water could theoretically get in. Technically true! Not useful!
The Ladybird team are C++ developers evaluating languages for a browser engine. When C++ developers say "OOP" they mean classes, inheritance hierarchies, virtual methods. The DOM is a giant inheritance tree. That's the context. You can tell them they're using the word wrong, but that doesn't change what they meant, and what they meant is the only thing that matters for understanding whether the claim made sense.
And under their definition-which is also the definition used by mass, essentially every working programmer and every university curriculum for the last 30 years-Swift and Rust are actually pretty close, which was my original point. Swift has `class` with inheritance, Rust has traits and composition. Neither is Smalltalk. The claim that Swift is "strictly better" was weird no matter which definition you pick.
(Also, and I say this respectfully: characterizing C++/Java/Rust as "functional programming" because they encapsulate data with functions is... a take. I get the logic chain you're following but that is not a definition that will help anyone communicate with anyone else, which is presumably the point of definitions.)
> When C++ developers say "OOP" they mean classes, inheritance hierarchies, virtual methods.
Okay, but for that to be true in this case then you must explain how Swift has "better OOP support". If there is no rational explanation for now Swift has "better OOP support" by the metrics you are imagining, as you, me, and everyone else has alluded to earlier, then clearly that isn't what they meant.
> I get the logic chain you're following but that is not a definition that will help anyone communicate with anyone else
Won't help communicate with anyone else meaning that you are the only one capable of understanding the logic chain? I'm sure you are a talented guy, but the world isn't exactly lacking in talented people. I'm sorry to say, but most everyone on HN will have absolutely no trouble understanding this.
> Okay, but for that to be true in this case then you must explain how Swift has "better OOP support" by that token.
I did. Swift has `class` types with implementation inheritance. Rust does not. If you're porting a C++ codebase with deep class hierarchies (like, say, a browser DOM), Swift lets you transliterate those hierarchies directly. Rust makes you rethink them into composition and traits. That's a real difference that matters to a team mid-migration, and it's an extremely rational explanation for why a C++ dev would say Swift has "strictly better OOP support."
You don't have to agree it's a large difference (I don't, which was my original point), but "there is no rational explanation" just isn't true. There's a very obvious one, it's just boring.
> If there is no rational explanation, as you, me, and everyone else has alluded to earlier, then clearly that isn't what they meant.
My position was never "there is no rational explanation." My position was "the difference is small enough that 'strictly better' was a weird thing to say." Those are different claims! You're kind of merging me into your argument when we don't actually agree.
> Won't help communicate with anyone else meaning that you are the only one capable of understanding the logic chain?
No, I meant that if you say "C++ is a functional programming language" to mass, any working programmer, they will not understand you, because that is not what those words mean to them. It's not about intelligence, it's about shared vocabulary. You've built a internally-consistent taxonomy where functional = data + functions, OOP = data + message passing, and imperative = data and functions separate. I can follow it fine. But you've redefined three terms that already have widespread, different meanings, and then you're treating disagreement as confusion. That's the communication problem.
> You've built a internally-consistent taxonomy
I'm certainly not clever enough to have built it. Not to mention that the person who coined OOP is quite famous for having done so. I am not him, I can assure you. I have merely ingested it from what is out there in widespread circulation.
I can appreciate that you live in a different bubble and what is widespread there is not the same. It's a pretty big world out there. However, it doesn't really matter as if "C++ is a functional programming language" doesn't jive with your understanding, as you'll simply ask: "What ever do you mean?" and which point "functional programming language" will be defined and a shared understanding will be reached.
This isn't the problem you are imagining.
> I did.
Right. Seems we encountered a communication barrier again. "That's the thing man, there isn't anything." in my world would read "That's the thing man, there are things and here they are: ..." However, this highlights again that it doesn't actually harm communication as further clarification follows and eventually everyone will reach a shared understanding. Communication isn't some kind of TV game show where you have to get the right answer on your first try. This is not a problem in any way, shape, or form.
2 replies →