abstract: the language was never the point

This week I published a bunch of new YouTube videos. Intro to Java. And they're not new because I've never made this content before. I made an intro to Java playlist about six and a half years ago back when I was adjuncting. It's been sitting there this whole time. Anyone could still watch it. The syntax really hasn't changed enough to make it wrong. But I'm back in the classroom this semester and I sat down to point my new students at this old playlist and I just couldn't do it. Not because it was incorrect, but because it looked and sounded like something from a different decade and I didn't want the first thing my students learned from me is here's a video where I looked like I'm auditioning for a different job. So, I spent part of my week off re-recording videos that, if you compare them line by line, teach almost exactly the same thing my six-year-old videos taught, which is a strange thing to sit with. But what exactly did I redo?

Welcome to Chaotic Commits. I'm Joanne, honest stories of building in modern tech. I've spent 16 years writing software and somewhere in the middle I took a little hiatus and I taught a little bit and I went back after COVID but now I'm back in front of a classroom again this semester and this week gave me a very specific very small lesson in a question that's a lot bigger than it looks. Why are we still teaching Java in college computer science programs in 2026? And what does the answer to that question actually matter as much as we act like it does? And um a little spoiler here, there are two things true at once. And I don't think either one lets the other off the hook. So let's get into it.

Here's what's true about my old playlist. The syntax is fine. Public static void still means what it meant six and a half years ago. A for loop is a for loop. Nothing in Java's core grammar has rotted out from under me. And that's true because these videos were never the class. They were prerequisite work. What a method is, how a for loop actually executes, how to declare a class, the raw mechanics. I hand them to students before the semester starts, so I'm not burning real class time reteaching syntax a video can cover perfectly well on its own. What has gone stale was everything around that syntax. The IDE I recorded on was an old version. My explanation of setup steps, reference tooling, that's changed. My own presentation was six and a half years less practice than now. And um I was a little younger looking. None of that is a knock on 2020 me. It's just what happens to teaching material. It doesn't age like wine. It ages like a screenshot.

The actual class, the one these videos exist to clear room for is object-oriented design. And I teach it in Java. And I'm going to be honest here for a second. I'm not convinced Java has to be the permanent language for that course. I think there's a real case for moving it to something else eventually. And I'll get into that in a minute. But I came back to teaching this semester after the gap and honestly I wasn't going to just do new college, new language, new grading rubric, new everything for the first semester. It just wasn't that kind of project. So I made a honest call. Keep the language that already had a working scaffolding for this course. Spend my actual time fixing the delivery on the prep videos instead and be straightforward with myself about the fact that keeping Java this semester was a "not yet" decision, not a "never" decision.

I think that distinction gets lost a lot in how we talk about legacy anything. And that can be in a codebase or in a curriculum. Sometimes you keep the old thing, not because you evaluate it and concluded it's the best choice, but because you did the math on what you could actually finish this semester and you made a call. That's not a failure of a vision. It's just a resourcing problem.

But it did make me sit with the question longer than I would have otherwise. If I'm not defending Java on the merits, why is it still the language most object-oriented courses, mine included, get taught in? Not just by me, but everywhere. So, let's give the institutional answer it's due because it's not a stupid answer. Even if it's not complete, Java is still the backbone of AP Computer Science A, a curriculum, which means a huge number of students walk into their first college CS class already written Java in high school. And that's not nothing. That's years of accumulated textbooks, autograders, and instructor experience built around one language. And switching costs real money and real faculty time to unwind. Java also forces a kind of explicitness that pedagogically is a feature and not a bug for a first course. You declare types, you handle your checked exceptions or the compiler tells you no. Nothing is quietly duck typed into working by accident. When a beginner's code runs in Java, it's harder for them to have gotten it there by luck because the language keeps making them say out loud what they mean. And there's a labor market argument to this, but it is weaker than it used to, but it's not zero. There is a volume of Java running in enterprise systems, and it's not going anywhere right now, and companies still want new graduates who aren't scared of it.

All of that is real. None of it is a lie professors are telling themselves. But you can notice what's missing from that list. Nobody in that list said Java is uniquely good at teaching object-oriented design better than alternatives. The honest version of the institutional case is closer to inertia with good reasons attached. Not a considered pedagogical verdict reached fresh every year. Departments keep Java a lot like I kept Java this semester. It's not because they relooked at everything from scratch and Java won, but because changing it is expensive and the existing scaffolding still basically works. That's a legitimate reason. It's not the same as a great reason. And I think computer science education would be more honest with itself if it said that part out loud instead of dressing inertia up as pedagogy.

I also want to name something directly because if I don't, some of you are probably already thinking it. Object-oriented design has a bad reputation right now and it's earned. You know the jokes. Somewhere out there is a real production class called AbstractSingletonProxyFactoryBean. And it's not a punchline someone made up. It's an actual name in an actually widely used framework four inheritance levels deep to represent a rule that probably could have been three lines. Interfaces created because we might need to swap the implementation someday and someday never comes. And now there's an extra file and an extra layer of indirection standing between you and the one line of logic that actually matters. Composition over inheritance becomes close to industry scripture for a reason. And a lot of the languages that got popular over the last decade look like they quietly designed their way around the whole problem. Go doesn't have inheritance at all. Rust builds everything around traits and ownership instead of class hierarchies.

So let's answer the honest question underneath your question. If the industry spent the last decade backing away from heavy object-oriented architecture, why am I even teaching this thing? Because the failure mode everyone's making fun of was never the object-oriented design. It was the object-oriented design used as a reflex instead of a decision. Reaching for a class hierarchy because that's just what you do. Instead of building the specific problem actually has a shape that benefits from building an interface for a component that will only ever have one implementation because a book somewhere said interfaces are good practice. That's not discipline failing. That's the discipline being applied with no actual judgment attached to it. And those are completely different problems. The same way if you hand someone a scalpel and you say go and they had no actual medical training.

So composition over inheritance, the thing that supposedly killed object-oriented design, that's not outside object-oriented design. That's object-oriented design working correctly. Knowing when a has-a relationship serves you better than an is-a relationship isn't an escape from the discipline. It's the discipline. The industry didn't reject object-oriented design. It rejected doing it badly on autopilot and then built new tools that made the autopilot version harder to reach for by accident. That's the practice maturing. Even the languages that look like they threw the whole thing out have not really a pile of pure functions operating over immutable records still needs someone deciding what that record actually owns, what exposed at the model boundary, what stays private to one file. Rename class to struct and interface to trait and you still doing the same design work. You just changed which keyword you type. The syntax moved, the questions didn't.

So, if I'm teaching object-oriented design in 2026, I'm not teaching reach for a class hierarchy every time. I'm teaching the judgment underneath it. When does modeling something as an object actually reduce the complexity of a problem? And when does it just relocate that complexity into more files with fancier names? That judgment is the actual skill. The factory factory jokes are what happens when no one taught it.

So why am I recording this as episode 19? Because when I was thinking about everything and I sat down to prep this class, I decided to re-record these videos. I pulled up my own object-oriented design course materials to see what needed updating. But encapsulation, inheritance, polymorphism, abstraction, what a class actually is versus an object versus an instance, when to use composition instead of inheritance, and why is-a and has-a are two different sentences with two different consequences for your code six months from now. None of that needed a single edit. Not one bit of it needed updating for 2026. And that's because none of it was ever really about Java, even though Java happens to be the language I teach it in.

So here's my analogy. Learning to cook is not the same as memorizing one recipe. If you learn knife technique, if you learn how heat actually behaves, how to build a sauce, how to season it as you go instead of at the end, that knowledge transfers. You can walk into French technique, Italian technique, Japanese technique, and that underlying skill, that actual competence comes with you. What doesn't transfer or transfers a lot less is the specific recipe card memorized word for word. That's useful exactly once for exactly one dish. Object-oriented design is the technique. Java is one recipe card. And for a long time, computer science education has handed students the recipe card and told them to learn to cook. Encapsulation doesn't care whether you spell it private or, or leading underscore. Polymorphism doesn't care whether your language calls it method overriding or duck typing or protocol conformance. The actual skill, the thing that makes someone a better engineer five years into their career is being able to look at a problem and ask, "What are the objects here? What do they own? What do they need to expose? And what should it stay hidden?" That question is language agnostic. It was language agnostic when I taught it in 2020 and is still language agnostic now. The language is the syntax you'll half forget within a year of switching jobs. The design is the thing you'll use for the rest of your career in whatever language your next job happens to hand you.

So, here's where I'm going to stop being purely a critic of the system and had to look at my own classroom. If I actually believe that object-oriented design is the transferable skill and the language is just the delivery vehicle, I can't say that out loud in October and then grade everyone strictly on Java syntax in December. That would be me not believing my own argument. So the final project in this course, in this object-oriented course is an open language even though I teach the semester itself in Java. Students can build it in Java. Sure, they can also build it in Python, in C, in whatever they're most comfortable with or most curious about with exactly one requirement. It has to demonstrate the object-oriented concepts we spent the semester on. Real encapsulation, a real inheritance or composition decision. They can explain and defend evidence they can understand what a class boundary is for, not just how to type the keyword that declares one. That single rule does more to test whether someone learned design than any syntax quiz could. A student who only memorized Java syntax will struggle to reproduce the same design thinking in an unfamiliar language. A student who actually learned object-oriented design will be a little uncomfortable with a new language's syntax and completely fine with the concepts because the concepts were never Java's in the first place. That's the test I trust. Not did you memorize this recipe, but did you learn how to cook?

So, I started this episode with a batch of new YouTube videos that teach almost exactly what my six-year-old videos taught. And I think that's the whole argument compressed into one weird little personal data point. The parts of my teaching that went stale were the parts that were never really about computer science. It wasn't about the camera setup or the IDE version or my delivery, whatever it was like six years ago that was less rehearsed. The parts that didn't go stale, not even a little bit, were the object-oriented design concepts underneath all of it because those were never tied to Java's compiler version in the first place.

Colleges keep teaching Java for a mix of good reasons and some lazy ones. And I think we do our students a disservice when we don't say clearly which is which. But the deeper mistake isn't the language choice. It's mistaking the language for the lesson. If your intro course is really teaching object-oriented design, the language is scaffolding. Necessary worth choosing deliberately, not the point. The day your final project rubric can't survive a change of language is the day you find out what you were actually teaching.

So that's this episode of Chaotic Commits. I'm Joanne Skiles who spent a week off re-recording herself explaining variables just to update the haircut and IDE theme and left the actual object-oriented lesson plan almost completely untouched. New episodes wherever you get podcasts. No highlight reel, just the commit history.