Can anyone who's actually dealt with Java tell me how much Anon is exaggerating?
I'm pretty sure Java doesn't have pointers, so writing a hello world application isn't gonna fuck up nearly that hard.
The one thing he forgot though is that your source file is probably in the folder
com/companyname/net/classes/factory/factoryfactory/worker/lib/bin/refresh/jdk/model/ui/closebutton/press.java
And spread out among a bunch of other directories, and the java file is like...3 lines. But there are 10k files spread all around directories like this that are all 3 lines a piece with a class definition.
Everything in Java is a hidden pointer
95% exaggeration. Here is reality:
Edit: typos
95% exaggeration if he is a real programmer.
If he just tried to walk into Java knowing nothing or maybe PHP, and refused to RTFA, he might experience about 30% to 40% of that I just trying to do everything wrong.
The rest is more or less spot on (no idea about concurrency issues though)
nullpointerexception is more likely the developper's fault
Of course it was the developer's fault. But it's absurd a language without pointers throws an error about pointers.
I've been programming in Java professionally for 11 years. It's not just embellishment, it's outright lying.
Threads giving you race conditions? All concurrent programming will do that if you're shit at it.
Java has come a long way. I will admit that UI in Java is terrible. I would never do that.
Java is religiously backwards compatible. Modern java projects are not as enterprisey and boilerplatey, but, as jdk21 is backwards compatible with jdk1.3, you can still happily write code as if it's 2003.
Additionally, the java space is huge, so just wildly googling will probably not help you that much.
It's much better today, but in 2010 that was 100% accurate.
That being said, using Java as a first time programming language is like a 15 year old trying to fly an airliner to get a few blocks away to pick up some after school snacks. Obviously it's way overkill. Sure you could get across town with it, but it's probably 1000x more complicated than just a simple bicycle or even walking.
Java is industrial strength for professionals. There's absolutely no consideration made for educational usage.
Only have a beginner perspective, but in school I did really well in intro CS class that used Python. 2nd class was in Java and it almost broke me I was so confused.
I have developed in java and C/C++ (many years) and Anon is maybe exaggerating a bit but not lying, we all have been there more or less.
Personally I hate how java forces you into bad architectural choices. Where is the unsigned int? Why isn't an int a class BTW? Why the pass by copy for some, by reference for others? Where is multi inheritance? Lots of things are dumbed down or you have no choice in the matter.
Sure didn't help it was a power hungry beast moving at snail speed back in the day too.
object orientated programming is the wrong idiom for almost all problems, and even in the few cases where it makes sense, you have to be very careful or it'll hurt you
I have been trying to be more functional but I still use classes for things like loading/modeling configs. What are some common situations where using an object is a good solution?
I use python if that helps at all.
What are some common situations where using an object is a good solution?
It depends on what you mean by "object"
When you have some kind of structured data, having a class to represent it is fine. If you're able to give it type annotations, that's much better than passing around random dictionaries.
When you need polymorphism and have an interface where some method on an object needs to exist (e.g. car.honk()), that's also fine as long as you avoid creating subclasses and using inheritance. If you need some car that can honk like a truck and drive like a racecar, use composition.
What I would consider a good use of classes (more specifically, nominal types) is dependent types. The idea is that you use the type system to enforce invariants for data.
For example, suppose you have a string for a user email. It might be a valid email string, or it might be garbage like "z#%@("=))??". You have a function for updating the user email in a database, and it requires the email string to be valid.
One approach is to validate the email string after receiving it from the user. That works, but what if your coworker creates a new form and forgets to validate the email string there? Bad data gets passed downstream to functions that expect well-formed data.
Another approach is to validate the email string at the top of every function that expects well-formed data. That also works, but now you're validating the same string multiple times and pasting validate_email(email) everywhere.
With a dependent type, you have a ValidatedEmail type and a constructor for it. The constructor will return an instance of the ValidatedEmail if and only if the email string is valid. Any function that expects a valid email will only accept a ValidatedEmail, and not a string. If your coworker creates a new form and forgets to validate the email, the type system will complain about a string being passed instead of a ValidatedEmail. You also shift the responsibility of validating the email to wherever there is a boundary between validated and unvalidated data, avoiding unnecessary validation since you know a ValidatedEmail is already valid.
It's an extremely useful paradigm for avoiding logic errors, but it's unfortunately not as common as it should be.
That's good advice but I would add that Java really sucks at using "the type system to enforce invariants for data" and that this approach doesn't have much to do with what most (especially Java programmers) would consider OOP. I die inside a little bit every time I need to use code generators or runtime reflection to solve a problem that really should not require it.
Just imagine how it must have been to code Minecraft 🤣
They only had to deal with LWJGL. The corporate java world has to use Spring.
Edit: They also had to deal with all the fans saying they should've written it in C#.
And much of the confusion and frustration at "Java" is actually because of Spring, or the "enterprise" nonsense making everything unnecessarily complex. You can just... write Java without any of that.
You shouldn't though, because Kotlin exists, which fixes everything that's wrong with Java while still being 100% compatible, so even in legacy projects you can mix and match and write new code in Kotlin without needing to rewrite any of the existing Java.
This is a place to share greentexts and witness the confounding life of Anon. If you're new to the Greentext community, think of it as a sort of zoo with Anon as the main attraction.
Be warned:
If you find yourself getting angry (or god forbid, agreeing) with something Anon has said, you might be doing it wrong.
