> even though it was EOL and Java 8 had been out for a while,
What's wrong with that?
You're supposed to cover the basics in intro to programming courses, and typically Java is not outright taught in college, and instead it's object-oriented programming using a random OO language, which more often than not is Java. Do you need to use Java20 to learn inheritance?
Also, unless you expect to work exclusively on greenfield projects, the bulk of any developer work is maintaining legacy applications. I still see an awful lot of projects in java 8 and only a few in java 11. Insisting on the latest and greatest java release makes as much sense as pressing to cover Lombok or Kotlin.
Do you need to prohibit Java 20 to teach inheritance?
Working with an outdated version as basis is fine, not accepting newer versions for no reason is something different imho.
> I still see an awful lot of projects in java 8 and only a few in java 11.
Sure, but that doesn't mean knowledge of newer features should be discouraged.
> Do you need to prohibit Java 20 to teach inheritance?
Java20 did not introduced inheritance, nor did it introduced any OO concept. Java20 adds no value to those learning OO. If you're writing java code but are not using any Java20 feature, you are not writing Java20 code.
> Working with an outdated version (...)
It is not outdated. You are not using any feature. You're just succumbing to the misplaced belief that new means more value. It doesn't, specially when the only thing that you get is more complexity.
> Sure, but that doesn't mean knowledge of newer features (...)
Repeat after me: Java20 adds no OO feature. You do not have to use Java20 to learn OO. OO courses are not java courses. Do you understand this?
> It is not outdated. [...] You're just succumbing to the misplaced belief that new means more value
Sure, technically you can still teach HTML in Internet Explorer 6 and OOP in Java 7 or something, but that has no added benefit and is actually more difficult to set up nowadays. And you can't deny that old versions are outdated when they don't even receive security updates anymore.
> the only thing that you get is more complexity.
What part of OOP basics got more complex in Java? And why teach Java at all if simpler OOP languages exist?
Not to mention that avoiding complexity can actually be counterproductive for teaching. As an example, I got more than 5 years of Java-focused programming education and afterwards I still didn't know what a classpath is and couldn't write a single line outside an IDE because nobody wanted to expose complicated stuff to the students. Instead of forbidding students from using a newer Java version one should focus on the actually important part.
The reason is it creates extra work for the teachers (having to keep up with newer features, bigger diversity of solutions they receive) without much benefit regarding the substance of what they need to teach.
Some universities choose a more “exotic” but more stable programming language for that reason (like SML or Scheme or Smalltalk), but then also get criticized because it’s not a major industry standard.
I mean, Java 8 had the lambdas and FP which I would argue are pretty important in modern Java.
But like, that’s the rule. I took a web class in college and the professor was teaching how to use <i> and <b> tags, which are no longer supported as part of the standard. (Not to mention that these days it’s not really helpful.)
I don’t just see this behavior in OOP style courses.
Most algos classes would probably benefit from streams, and there are many of them being taught in Java for reasons unrelated to OOP. Universities often stick to one language for much of the programming curriculum.
To prove two points: First that forcing objects everywhere makes things really complicated compared to FP, second that under the hood everything can be shoehorned to object model.
Frankly if you want to teach object oriented languages, you should be teaching Smalltalk or Objective C, not things derived from C++. Message passing is the defining feature of object orientation.
If the intent is actually to teach polymorphism and encapsulation, both of those can be done in raw C.
The question is then, why should object oriented languages be taught? It seems to me that for last 25 years or so the true object orientation has been a historical curiosity that inspired polymorphism and encapsulation and only interest for people who want to argue that this and that language aren't true object oriented languages.
Indeed: I wouldn’t bother. Teach procedural and functional programming to undergrads as primary focuses.
However, polymorphism and encapsulation have existed for much longer than “OO” languages. What is stdout? Seems pretty polymorphic to me. How does one gain access[1] to a variable declared in a .c file that is not exposed via the header. That’s encapsulation…
[1]: there are of course ways, but they are often also true of private members of class instances too.
Good point. I was thinking about the C++/Java meaning of the words because that way of doing things has proved to be useful but they're not the only way indeed.
What's wrong with that?
You're supposed to cover the basics in intro to programming courses, and typically Java is not outright taught in college, and instead it's object-oriented programming using a random OO language, which more often than not is Java. Do you need to use Java20 to learn inheritance?
Also, unless you expect to work exclusively on greenfield projects, the bulk of any developer work is maintaining legacy applications. I still see an awful lot of projects in java 8 and only a few in java 11. Insisting on the latest and greatest java release makes as much sense as pressing to cover Lombok or Kotlin.