this post was submitted on 15 Jul 2023
1190 points (98.9% liked)
Programmer Humor
19480 readers
30 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Compare:
x.field[5]with
x.getField().get(5)Both are exactly the same level of OOP, but the Java version is roughly twice as long. Add operator overloading to the mix and it becomes much worse:
x.getField().get(5).multiply(6).add(3)vs
x.field[5] * 6 + 3All this has nothing to do with OOP, but with syntactic sugar that is applied.
As I said, the convention is now x.field() not x.getField()
What language are you comparing against here? x.field[5] is valid Java if field is a public array, but that's not OOP, at least not in a pure sense.
It's not valid Java for e.g. Lists, Maps, Strings or any programmer-defined classes.
Same with operator overloading.
myVectorA + myVectorBis not valid Java, but it is valid OOP in e.g. Python or C++. And this kind of syntactic sugar reduces verbosity enourmously, while still being OOP.If you have ever worked in e.g. Python, Groovie or Kotlin you notice quickly how non-verbose OOP can be.
It seriously is just Java.
And Javas insistance on having you wrap non-OOP things in fake OOP constructs (e.g. static methods, which are just functions in modules, but you have to uselessly abuse classes as modules) isn't helping either.