Closing this as we are no longer pursuing Swift adoption

> 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.

> I'm certainly not clever enough to have built it.

Ha, don't sell yourself short, you're doing a great job defending it.

> However, it doesn't really matter as if "C++ is a functional programming language" doesn't jive with your understanding, you'll simply ask: "What ever do you mean?"

Okay, genuinely, let's try this exercise. You say to me "C++ is a functional programming language." I ask "What ever do you mean?" You say "data is grouped with functions." I say "...that's also true of Python, JavaScript, Kotlin, Scala, Dart, TypeScript, and basically every language designed after 1990. What term do you use for Haskell?" And now we're in another 20-message thread defining terms from scratch instead of talking about the actual thing.

Like, you've got a taxonomy where imperative/functional/OOP is a clean trichotomy based on how data relates to code. That's elegant! But it also means "functional programming" contains both Haskell and Java, which in practice need to be distinguished from each other far more often than they need to be grouped together. The Kay-pure definitions give you clean categories at the cost of useful ones.

*Obj-C doesn't even pass muster of the Kay-pure definition, which renders the whole conversation moot.*

> "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: ..."

Okay, fair hit. :) What I meant was: there's nothing that would make a C++ team say "strictly better." Swift has classes with inheritance, sure. But "strictly better" implies Rust can't even get close, and it can-you just model things differently. The Ladybird team discovered this themselves, which is... kind of the whole story here? They said "strictly better OOP support," tried it, and now have removed Swift. The claim didn't survive contact with their own codebase. That was the entire point of my original comment sitting at -3. (now at +2)

> Communication isn't some kind of TV game show where you have to get the right answer on your first try.

No, but Hacker News comments at -3 do get grayed out and collapsed, so in practice it kind of is, unfortunately.

Indeed, chapter 18 in The Book stops short of claiming that Rust is object oriented. But it's clearly written to highlight the good parts of object-oriented design that Rust has adopted.

Have you looked at all the previous attempts?

Your example is not compelling I’m afraid but you should try building a language to see. Also read literate programming if you haven’t already.

Reminds me a bit of the fish anecdote told by DFW... they've only swam in water their entire life, so they don't even understand what water is.

Here are the mixed paradigms/styles in these Python snippets:

- Statements vs. expressions

- Eager list comprehensions vs. lazy generator expressions

- Mutable vs. immutable data structures / imperative reference vs. functional semantics

(note that the Raku version only picks _one_ side of those)

> seq.extend(sum(seq[-2:]) for _ in range(18))

I mean, this is the worst Python code yet. To explain what this does to a beginner, or even intermediate programmer.... oooooh boy.

You have the hidden inner iteration loop inside the `.extend` standard library method driving the lazy generator expression with _unspecified_ one-step-at-a-time semantics, which causes `seq[-2:]` to be evaluated at exactly the right time, and then `seq` is extended even _before_ the `.extend` finishes (which is very surprising!), causing the next generator iteration to read a _partially_ updated `seq`...

This is almost all the footguns of standard imperative programming condensed into a single expression. Like ~half of the "programming"-type bugs I see in code reviews are related to tricky temporal (execution order) logic, combined with mutability, that depend on unclearly specified semantics.

> It's about twisty stupid special symbol meanings.

Some people program in APL/J/K/Q just fine, and they prefer their symbols. Calling it "stupid" is showing your prejudice. (I don't and can't write APL but still respect it)

> What's not fine is to make up bogus comparisons and bogus implications about the people who don't like it.

That's a quite irrational take. I didn't make any bogus comparisons. I justified or can justify all my points. I did not imply anything about people who don't like Raku. I don't even use Raku myself...