[kasey_junk]

What programming job are you getting in the next few years that understanding oo isn’t important?

Inheritance, polymorphism and encapsulation inform every major professional programming language and framework (except c). Even go which in many ways is active response to oo uses most of those concepts extensively. One major challenge of people programming in go is how to adapt the familiar patterns to it.

Now I’d probably not teach the whole GoF as an exercise in cataloging patterns but teaching a few of the most common while showing the concept of patterns (probably the least well understood concept in development) seems sensible.

[tptacek]

My argument accepts the idea that you're likely to come across object-oriented code in your first jobs in the field, the same way you're going to come across complicated SQL joins, which is also something a CS curricula is unlikely to prepare you for. I would advocate for delegating OO concepts to that kind of level of "trade knowledge" rather than elevating it to a "fundamental" of computer science.

Rust and Go have concepts that approximate class-based object-oriented programming (and: if you look at NEU's OO syllabus, that's what they're doing), but only barely. You could teach someone how to use an interface without teaching "polymorphism" as a concept. Encapsulation as a language feature is an example of an OO-ism that I think is done and dusted. We hid implementation details in C, too! The notion of an abstract data type is fine to hold on to. The idea of "friend classes" and "protected" fields and other ACLs for variables, though, I don't think we're going to see come back.

[kasey_junk]

OO elevated encapsulation, inheritance and polymorphism to fundamental language features. Polymorphism especially has become ubiquitous in modern languages in the same way types have.

And perhaps we’ve moved past inheritance hierarchies (though multi/parent inheritance has been interestingly used recently) but even then, knowing about it and its negatives seems as fundamental as understanding goto.

Are they on the programming side of the computer science curriculum rather than computational math? Yes! But much of the normal curriculum is. Similar to how I’d expect the relational calculus to be taught as well as how sql relates to it.

I think you’re pretty far out on a limb here and I’d be very skeptical of a curriculum that didn’t have a segment on oo early on.

[tptacek]

I'm comfortable being out on this limb! I think there were OO-skeptics even at the height of OO (call it the Ruby/Java crossover period; or, maybe, the point at which Norvig gave his patterns presentation, 5 years earlier) and I think the skeptical take looks pretty strong in retrospect.

Whatever you want to say about the OO inspiration of how Rust and Go are structured, they are both clear and deliberate rejections of the OO orthodoxy from that period. They both deliberately don't have classes. They both deliberately eschew inheritance. They both deliberately have less-granular, less-configurable "encapsulation" rules.

And: "encapsulation" is a term we only have because of class-based object-oriented programming. As a professional C programmer in the 1990s, I'd have gotten dinged on a message board by a C++ person if I claimed that I was "encapsulating" when I hid the structs for my timer library or my trie library behind a void pointer. We had abstract data types long before mainstream class-based OO, and then class-based OO claimed credit for the idea.

I also think, as you've alluded to here, mainstream OO has a lot of bad ideas that get people in trouble. The obvious one is animal->mammal->cat->tabby, but there's also the debacles that happen when people try to unify storage with the same inheritance ideas used by compute.

More than anything else though, I think these are the kinds of details you can just learn on the job. What's fundamental to programming? Ironically, it's a lot more of the stuff you get in a Scheme-based class --- and I'm saying this as someone who does not like Lisp. I think Python is a step in the right direction here.

[kasey_junk]

Go absolutely has classes, polymorphism and encapsulation (I don’t know Rust) and many, many packages in go follow extremely common OO patterns.

The 2 differences in go are composition being the mechanism for inheritance and structural typing in an otherwise strongly typed language. Both of those were available in other languages that strongly identify as oo.

My first cs class was taught in scheme. I think that’s the _right_ way to begin to learn. But very quickly after that oo and imperative ought to be introduced.

[tptacek]

I would sum my career up as C -> C++ -> Python/Ruby/Python -> Go -> Go/Rust, and would say my experience of Go (reinforced in Rust) was sharp pushback on class-based OO idioms, especially inheritance.