I agree that it's better to focus on encapsulation/polymorphism/reuse, but the reason why I personally object to the idea that "for any regular working day programmer Rust is obviously OOP" is because inheritance is usually taught above all of these as the fundamental property of OOP.

I doubt I'm the only one whose high school and college exposure to OOP was to model "Dog is-a Mammal, Cow is-a Mammal, Mammal is-a Animal", and if a newcomer to Rust tries to do the same as their "hello world" then they're going to be greatly frustrated. Again, this isn't to say that the phrase "Rust is OOP" is necessarily incorrect, only that it's going to backfire if we going around shouting it, due to misaligned expectations.

Agree 100%. And I think that what is commonly thought of OOP (the Java model) suffers greatly from real-life analogies like that. Not everything fits into neat hierarchies – not in real life and not in code.

I also think that the concept of "class" suffers from a great amount of un-orthogonality. A class packages together a memory representation, an encapsulation boundary, an interface that defines functionality and a unit of type parametrisation. I find the way how Rust separates modules as the unit of encapsulation, traits as the unit of functionality and structs as the units of memory representation, very elegant.

Now if one could type-parametrise modules...

Ahhh the elegance of SML rears it's beautiful head :-)

That only happens when the teachers do a bad job not explaining interfaces, protocols, components, categories.... or as Rust puts them, traits.

What kind of polymorphism? Traditional OOP is subtype polymorphism. You can't really do that in Rust. It's main polymorphism is parametric and ad-hoc polymorphism a la Haskell. If that's considered OOP then OOP is so broad it's not a useful term

What is traditional OOP?

The Simula, Smalltalk, Lisp, SELF or BETA model?

Yes, OOP is broad, just like FP also is.

I don't think that "is-a" is formally defined anywhere. In my school experience, using Java specifically, "is-a" was used to teach the `extends` keyword, while "has-a" was used to teach the `implements` keyword.

> Obviously Rust is in the 4'th school which I like to call "The Rust School".

Ha! But yeah, if you're going to claim Rust is OOP, I would argue that makes the most sense.

> what really matters is that Rust gives you:

Right, this is the "Java School" definition. However, when people talk about OOP this way, when they say "polymorphism", they mean "subtype polymorphism" not "parametric polymorphism." Take https://docs.oracle.com/javase/tutorial/java/IandI/polymorph... as an example. Rust's only sub-typing is for lifetimes.

> As fun as the PL theory discussions are.

I definitely agree that in some senses, this is academic. But at the same time, practitioners can be mis-led by using terms in a different way than they're used to. This is sort of the argument I'm making above; since many practitioners see "polymorphism" as being equal to "subtype polymorphism", calling other types of polymorphism "polymorphism" is a more academic, less user-focused distinction.

Oh dear. That java tutorial just reads wrong to me but that's probably because I've been burned too many times by conflating polymorphism with code reuse in the form of inheritance.

I think the working programmer doesn't know or care though. They care about whether you can reuse code in some way. And whether you can substitute multiple implementations of an object act as one particular type.

The specifics of how you reach either of those goals is all they want to know and the pedantry that us language geeks love to engage in just blows right past them.

It's possible we've just interacted with different people; I've spoken to a lot that assume inheritance, specifically, and we get questions about it often.

Anyway, thanks for a good discussion!

It's highly possible. I almost never get to work with people who geek out over language theory :-D

I have to come to HN for that instead.

> Encapsulation, Polymorphism, And Code Reuse.

These are three incredibly vague terms that pretty much every programming language can be said to provide. I can't understand how you think OOP is defined by this.

Do you think Haskell programmers are unable to reuse code? That they don't have any form of polymorphism? That they can't hide implementation details of functions, data structures and modules?

This is the kind of argument that convinces me that OOP is completely bunk. Its adherents can't even explain what it is!

> These are three incredibly vague terms that pretty much every programming language can be said to provide. I can't understand how you think OOP is defined by this.

I do not want to defend OOP, but I would like to add that object-orientated languages are often to be expected to support these 3 things (encapsulation, inheritance and polymorphism) - at least many sources list these properties as must-have to be considered object-orientated.

> This is the kind of argument that convinces me that OOP is completely bunk.

Agreed. E.g. functional programming has a sound foundation (λ-calculus), but in object-oriented land if often sounds a little bit hand-wavy.

I wouldn't call myself an adherent. If anything I'm an adherent to the idea that Objects are just another Closure and vice versa. The interesting distinctions are in how they achieve those same goals.

But most working programmers don't care about the debate at all in my experience. When they say they are looking for an object oriented language what they are really saying is:

    I am looking for a language that has a syntax where you
    can declare an object and call methods on that object 
    usually with a dot but sometimes with an ->.

They don't actually care about much more than that most of the time.

> I'm looking for a language with "objects" and a syntax like <this>

But why? That's such a weird thing to look for. Clearly there's a reason they think they want "objects", but what is it? And why the focus on what syntax these objects have?

I'm not arguing this is a good thing. But I am saying that for the vast majority of programmers out there they use that pattern as a way of determining if they have those three attributes. It's cargo cult programming in a sense but it's also the only signal they've ever known.

I think calling Rust that would confuse people more than anything. They will look for their traditional inheritance style relationships and be frustrated that there is not really any support for it. Better to teach the features that Rust actually has, than to try and fit some uber generic definition of "Objects" that's not going to serve newcommers.

Code organisation. Classes are basically used as datatype specific namespaces.

In Haskell you have to deal with the possibility of record types sharing the same field names.

> Which are the only three things anyone who reaches for OOP is really looking for anyway.

Those are 3 characteristics of modularity, not object or class-specific in any meaningful sense. Rust isn't really a classic object-oriented language, but it is a modular language with object-like abstractions.