[ilovecaching]

How so? I believe I was addressing the fundamentals of OOP: Classes, methods, inheritance, overloading, visibility, etc.

Also, Rust, while allowing the assigning of behavior to a type, is explicitly not OOP. Check it's Wikipedia page (which doesn't include OOP in the list of paradigms) and the O'Reilly book (which says Rust isn't OOP).

[Aloisius]

Under the original definition of OOP as various alternate definitions, Rust would be OOP. This is all covered here:

https://doc.rust-lang.org/book/second-edition/ch17-00-oop.ht...

Personally, I think the idea that code isn't OOP just because you don't use inheritance to be utterly ridiculous.

[steveklabnik]

So, I wrote that chapter, and part of why we don't really discuss definitions is that there are so many conflicting ones. Instead, we tried to focus on goals, and how they'd apply to Rust.

Personally, I believe the two big OOP definitions are "Java OOP" and "Smalltalk OOP", and Rust fits neither. People coming from heavy OOP backgrounds really struggle with Rust for this reason. It's also why this chapter was the hardest one to write.

Java: https://docs.oracle.com/javase/tutorial/java/concepts/ (Sometimes phrased as "Encapsulation, Inheritance, Polymorphism, Abstraction")

Smalltalk: http://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented

[ilovecaching]

Except that Rust lacks almost all of the features and terminology you'd expect of an OOP language. Again, I take OOP to mean what one learns in school... A class based language with inheritance, overloading, visibility of members, constructors, etc.

Rust can define behavior on any type of data, including scalar values. There is no concept of a "class" and constructors and simple functions that return instantiated values. They are not automatically called when a value is instantiated. Traits are more like interfaces, they constrain an implementer. A value has no way of inheriting behavior. Visibility is at the package level, and Rust offers no notion of encapsulation inside of a package.

Rust is, by the trending definition of OOP, not OOP.

[derefr]

> Again, I take OOP to mean what one learns in school

Don't do that, then. "OOP" is a term-of-art in an academic discipline. It means exactly what it was used to mean by the people who coined the term in the papers they coined it in.

The thing that schools teach under the name "OOP" is a https://en.wikipedia.org/wiki/Lie-to-children intended to introduce something vaguely like OOP, not to introduce OOP itself.

---

And, before you ask: no, there is no academic jargon term for "the thing that C++ and Java are." From an academic perspective, neither language has any particular unifying semantics. They're both just C with more syntax.

OOP is a different set of semantics, based around closures (objects) with mutable free variables (encapsulated state), where an object's behavior is part of its state.

C++ and Java can simulate this—you might call this the Strategy pattern—but if you build a whole system out of these, then you've effectively built an Abstract Machine for an actually Object-Oriented language, one that ends up being rather incompatible with the runtime it's sitting on top of.

[loup-vaillant]

Most people take "OOP" to mean what schools told them. And that's why "OOP" does mean that. Because most people vaguely agreed on some blurry definition, and use it.

The fact that "OOP" is no longer used to point to what Alan Kay originally meant is immaterial. It's a shame, but that train has passed.

[derefr]

I know you're arguing for "words are communication", and I'm a writer, so I certainly I agree with that. In general.

OOP is not a word, though. It's a jargon term. You can't redefine those. They mean what they originally meant, because if they don't, then you lose the ability to understand what the people doing real work using the word by its proper definition are doing. Jargon terms don't drift.

To be clear, I'm mostly talking about the same thing that is true of the term "Begging the question." Laymen can use it to mean whatever they want—and I don't begrudge them that, it's a phrase in a language and people will do what they like with it. But that lay-usage will never change what the phrase means in the context of formal deductive reasoning.

Likewise, programmers can use "objects" and "OOP" to mean whatever they want it to mean—but when having a formal academic discussion about programming language theory, an "object" refers to a specific thing (that came about in LISP at MIT before even Kay; Kay just was the first to write down his observations of the properties of "objects") and "OOP" refers to programming that focuses on such "objects" (as implemented in Smalltalk, CLOS, POSIX processes, Erlang processes, bacteria sharing plasmids, or computers on a network; but not by C++ or Java class-instances.)

I don't think we disagree, here; you're arguing that the lay-usage is X, and the lay-usage is X. I'm just pointing out that the lay-usage is irrelevant in the context of a discussion that requires formal academic analysis of the concept.

[dragonwriter]

> OOP is not a word, though. It's a jargon term.

Jargon terms are a subset of words.

> You can't redefine those.

You can. Anyone that's been around computing knows that “functional programming” (and even “imperative programming”, which at one point contrasted with structured programming) have drifted

> Jargon terms don't drift.

Jargon terms absolutely drift (and get overloaded) for the same reason as other terms do,the difference is the community of use in which those factors which drive drift/overloading operate.

> To be clear, I'm mostly talking about the same thing that is true of the term "Begging the question." Laymen can use it to mean whatever they want—and I don't begrudge them that, it's a phrase in a language and people will do what they like with it. But that lay-usage will never change what the phrase means in the context of formal deductive reasoning.

Mostly aside, but the popular alternative usage of that phrase is transitive verb phrase, and the older usage is an intransitive verb phrase (which, while this is clearly reversing the etymology, can be viewed as a special case of the transitive form with a particular direct object assumed) so the two neither conflict nor are incompatible. So, it's kind of a bad example of anything other than reflexive pedantry; accepting the alternative usage in formal circles wouldn't be drift or overloading because it is structurally distinct.

[ilovecaching]

Yep

[Chabs]

I didn't mean rust was fundamentally OOP, but that rust implements, through runtime traits, exactly the behavior you are criticizing OOP for. Sorry about that

[ilovecaching]

Can you please point out exactly what I said when you say 'the behavior I'm criticizing OOP for'. Haskell typeclasses are very different from OOP inheritance or OOP classes. In any case, I don't see how that relates to the explicit criticisms I made.

[Chabs]

> All in all, OOP is a toolkit for building bad abstractions: abstractions that do not easily model computation, that hide data.

That's a fundamental property of type erasure, which is not exclusive to OOP, and far from the extent of what modern OOP is about

[ilovecaching]

I don't think you understand what type erasure is.