[tptacek]

Teaching object-oriented design as fundamental computer science seems like it would have been an odd decision for 2025. I looked up the class syllabus, and it seems to have been taught in Java (fine) and makes extensive reference to design patterns (not fine).

[geokon]

I once asked a professor about this and the answer I got was interesting.

Basically Java and OO and Design Patterns are taught upfront because it turned out this was a huge stumbling block for a lot of people. Bigger than for instance C and pointers. Like it just doesn't click for a lot of people and they end up struggling a lot the rest of the major

So it's not that these are the most crucial concepts, but you want people to "fail fast" and have a sense if they'll succeed in the major within the first year

[tptacek]

Right, so... just don't teach Java and OO at all? They're not fundamental. Some of the ideas in that course are something closer to discredited.

Later

I edited "a lot of" to "some of"; I was coming on too strong.

[wbl]

If by discredited you mean incorporated into many of the most used languages as well as several of the hot new ones then yes.

Furthermore part of PLT is learning the past and what worked and what didn't.

[tptacek]

I don't think that literally means learning how to write AbstractFactories in Java.

[dehrmann]

This makes sense. You might not immediately need to design a complex hierarchy, but you'll encounter them pretty early in a lot of languages standard libraries.

[weitendorf]

The first time I tried to learn how to program, I was 12-13 years old and found some video from a university that started by covering Classes, Methods, and Objects.

I watched one or two lectures and it made no sense to me, so I gave up. I had no idea WTF "objects are like nouns and methods are like verbs" was trying to teach me. I just wanted to make my computer do things.

Around 14-15 I started playing around with my TI-84 calculator writing simple programs. The TI-84 used a form of BASIC where I could write a program that took INPUT and plugged it into an equation and print it to OUTPUT, and it felt so much more approachable than the neo-neo-platonist OO lectures I'd watched. From there I gradually started writing more complicated code until I eventually started to get why programmers would define functions to stop repeating themselves, or why they might implement custom types.

> So it's not that these are the most crucial concepts, but you want people to "fail fast" and have a sense if they'll succeed in the major within the first year

I'd instead posit that so many people "fail fast" with OO because they go into their class being interested in programming, but have no idea wtf is even going on with programming and drop it, because they're forced to learn all this inane trivia [0] and write all this boilerplate (define a class, methods, observability, return by value vs ref) they don't understand before they can even run a program. They think maybe they're stupid or not a good fit for programming and drop it.

IMO a better teaching language would be one that lets you opt-in to OO and functional features but also lets you write really simple programs like "take a number, multiply it, and print it". I think that's why Python is so popular these days. It helps that the lack of semicolons/curlies, optional typing, and modifiers [1] removes so many distractions and gotchas that stymie absolute novices.

I also think most CS educators do a very poor job explaining CS concepts to beginners without realizing it. "Methods are like verbs" is absolute nonsense without a moderate to large amount of computer science knowledge to contextualize it. Some of my teachers were actually pretty good, and I also don't remember much acknowledgement that programming didn't have to be this way but that the language/tool was designed that way because that abstraction comes in handy. That'd probably help a lot in retaining students who successfully suffered through their first semester of CS 101 in Java but hated it so much they decided to swear off programming.

[0] Always start your program with "public static void main(string[] args)" ! Don't worry, that'll make sense in a year, or in six years when one day on the toilet at your software engineering job you realize that it really was a static function returning void that took string[] args

[1] Static and Foo& are justifiable, although static should arguably be implicit for a beginner language. Forcing students to learn about final, const, val/var, public/private, etc. early on is just stupid. I never understood why these were actually useful, or had a good reason to use them, until I'd already graduated.

[naijaboiler]

Brilliant. And correct. The people who created this concepts landed there after going through similar paths like you did (i.e. they started somewhere straightforward but eventually invented these complexities out of necessity.) They understand they "why" behind it.

But somehow, in the curriculum, we expect complete noobs to just get this abstract, non-relatable concepts without any contexts.

[mywittyname]

There's some irony here. These courses exist because years ago, CS departments made a shift towards "marketability" in their courses at the expense of "fundamentals". So they introduced Java to replace C++ because that's the language companies hiring new grads were looking for. And now OOP and Java are not skills that companies are looking for in new grads. But instead of acknowledging the facts, the departments are lumping Java+OOP in with "fundamentals" and getting rid of it.

I'm sure if we look back further, C++ displaced some other language (pascal?) for exactly the same reason. And likely the same for the language the proceed C++. I'm just not old enough to have personal experience here.

[bakuninsbart]

OOP is one of the major schools of programming, significantly more widespread than functional languages. The only thing arguably used more is "simple" procedural, but even that is doubtful. Sure, in the 90s people thought OOP was the be-all-end-all, and we've moved away from that, but it still makes complete sense to teach the main different styles of programming. C and assembly are basically covered by a course on computer architecture and OSs, then teaching an intro course on both FP and OOP gives students a broader understanding on how the vast majority of program design works. Follow up courses on algorithms can then have synergy by showing how much easier/safer/faster they are to implement depending on the style.

[tptacek]

I reject the idea that OO is a "major school of programming"; or, if it is, that school has been largely discredited. I think you're on firmer ground if you claim that ideas from OO still inform modern programming (traits and interfaces being a good example).

I think a lot of 2025 developers would be alarmed to think that a project had started from an object-oriented design perspective.

[bakuninsbart]

That's a bubble thing. The vast majority of serious software engineering is done in OOP. Java, C# and C++ alone are more than half the market, and then you have Python, Ruby, Kotlin and many more. Even JS has moved largely to (bastard) classes.

Then you have data (growing above average), scripting and partially frontend that are done differently, but they are still a minority of the job market.

[tptacek]

If it was 2005 I would take this argument pretty seriously, but it's 2025 and I find it less plausible. Python has (somewhat dumbed down) OOP features, but modern idiomatic Python tends not to be domain-modeled intricately-encapsulated OOP; in fact, it's increasingly functional. You bring up Javascript, and my retort is React: the most popular UI framework in Javascript --- UI frameworks being the archetypical case of a problem domain well-suited for OOP --- is largely a rejection of OOP principles and a marked shift towards functional programming.

(I'm not a Lisp or functional partisan; like I said downthread, it's Go and Rust for me these days mostly).

Keep my original point in mind here, which is simply that OOP principles are not a fundament of software development in the same way algorithms, data structures, memory models, and concurrency are. We're discussing curricula that have students learning class-based object-oriented programming as expressed in Java as a requirement, and basic systems programming as an elective. That's backwards.

I don't care if you still use OOP. I'm not advocating for its removal from production codebases. There are plenty of things that earn their keep in modern product stacks that aren't fundamentals of computer science!

[mixmastamyk]

It's still useful sometimes. Right now I have a functional-style program I think would be easier to write if was redesigned in Mixin-style OOP. Usually happens the other way, but not always.

[tptacek]

I don't think it's useless so much as that it's not on the same tier of fundamental importance as structured programming, the memory hierarchy, concurrency, functional decomposition, recursion, trees, tables, and graphs.

And when you look at what the actual classes teach: it's usually patterns-y Java. GoF patterns are effectively obsolete. You might still need to grok them, but that's trade knowledge, not fundamental computer science. You don't come out of a CS degree knowing Hibernate or SAP, either, but people figure it out on the job.

[criddell]

What's the problem with design patterns? At its core, a design pattern is just a name applied to a frequently used code pattern. It gives us a common language. I can tell you we are using a publisher-subscriber model and you know what that is without me having to be super specific.

[tptacek]

The concept of a design pattern is ~fine, and people have done good work applying the concept to specific programming domains (concurrency being the best example I can come up with), but "Gang-of-Four"-style design patterns are just workarounds to the limitations of the languages those authors were grappling with at the time, and are deeply silly in modern code, mostly living on today as an AbstractFactoryFactory joke.

[chris_wot]

If you are going to teach OO in Java, I fail to see why teaching design patterns is so awful.

[tptacek]

I mostly point it out as a reason why teaching OO as a fundamental is a bad idea in the first place.

[andrewstuart]

But OO is a fundamental, even if it isn’t longer gospel.

OO is important and if I’m three years of computer science there’s no time to teach it then you have to ask what you’d heck they are doing.

OO is everywhere and it’s an important software concept and is the right solution for certain classes of problem.

[tptacek]

I disagree? The point of a CS degree isn't to prepare you for the 20 years of stale J2EE code your first job is going to throw at you, and object-oriented design is pretty out of fashion.

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

[cmiles74]

People are still writing OO code today, they way the industry stands it looks like people will still be writing OO code for at least the next decade. Maybe the next 20 years, even.

I understand that not every developer is a big fan of OO but that doesn't mean we can ignore it.

[jeroenhd]

OO is one of many paradigms to take while programming. Between functional programming, C-style subroutine programming, and OO, or the more recent amalgamations of those, you pick whatever suits your problem best. It's perfectly useful to teach, even if you dislike OO programming. I don't like writing for outdated programming designs like Scheme or LISP either, but that doesn't mean they don't have anything useful to teach.

OO is out of fashion just like blockchains and NFTs are out of fashion, and the same way AI will fall out of fashion in the future. The huge hype around it will die and what's left covers the few useful scenarios.

[andrewstuart]

>> and object-oriented design is pretty out of fashion

OO isn't debunked and its not out of fashion.

All that's happened is that it's no longer gospel that "the only way to program is OO".

I write code that has all sorts of styles and approaches that fit the task at hand and sometimes the right tool for the job is OO.

I get the sense you're saying that OO has been proven to be hokum and no one should learn it or do it anymore and all that remains OO is the smoking ruin of 20 years of Java. That's not correct at all.

[DiggyJohnson]

You’re assuming an exaggeration of their point. The question at hand is whether OO is so fundamental as the backbone of a computer science 101 course. This doesn’t preclude much of what you said.

[naijaboiler]

how did it ever become gospel. given the diversity of human experiences, and the the diversity of problems we have to tackle, it is near impossible for there to be one and only way to solve a problem.