Welcome to java, we have a couple unconventional ways of doing things, but overall I'm like every other mainstream oo language.
People: AHH! Scary!
Welcome to python. your knowledge of me wont help you elsewhere as my syntax is purposefully obtuse and unique. Forget about semicolons, one missed space and your code is as worthless as you after learning this language.
"No, I don't use type annotations because they don't actually do anything. In fact I purposefully give this parameter different types for different behaviors. How is that confusing?"
This still uses preview features though. However, like you demonstrated already, compilation is no longer a required step for simplistic programs like this.
It must be somewhere under the hood. Otherwise, it wont be callable and it would require an instance of an object to call. Unless the object here is the Java environment?
No String[] args
They are just optional I'm sure, like C and C++. You still need them to read command line arguments.
All in all, these syntax improvements are welcome. I already moved on to Kotlin for Android development though.
I got the impression they skipped the hello world cause it was too easy and they wanted to get right to writing their app, so they moved on to more advanced stuff without having a real grasp of the basics
Java is terrible and I hated it but I feel like this stuff is not why, this mostly just seems like stuff that most powerful object oriented languages do.
Java is amazing and I love it, and I agree that this is not really a good list of problems. (Not that I expect green texts to be well thought out, rational, real, fair, or anything other than hyperbolic rants lol.) There are good reasons to critique it and the ways people use it, but this isn't it.
Particularly funny is the one about race conditions. That's something you'd have to deal with in any sort of multi threaded environment.
Honestly, I prefer C to Java, it's incredibly simple without all the BS that Java throws at you:
interfaces - compiler will fail if you provide the wrong types; w/ Java, figuring out what types to pass is an effort unto itself
functions - everything needs to be in a class; even callback functions are wrapped in a class (behind the scenes if you use modern Java); in C, you just pass a function
performance - Java uses a stop the world GC, which can cause issues if you have enough data churn; in C, you decide when/if you want to allocate or free memory, no surprises
There are certainly some bad parts, but all in all, when I run into an issue in C, I know it's my fault, whereas in Java, there are a million reasons why my assumptions could be considered valid, and I have to dig around the docs to find that one sentence that tells me where I went wrong w/ the stuff I chose.
That said, I prefer Rust to both because:
get fancy stack traces like I do in Java (I really miss stack traces in C)
compiler catches most of my stupid mistakes, Java will just throw exceptions
still no stupid interface hell, I just satisfy a specific trait and we're good
generally pretty concise for what it is; I can rarely point to a piece of syntax and say it's unnecessary
I use:
Python - scripting and small projects
Rust - serious projects or things that need to be fast
Go - relatively simple IO-heavy projects that need to be pretty fast
C - embedded stuff where I don't want to mess w/ the Rust toolchain
Java has been absent from my toolbox for well over a decade, and I actively avoid it to this day because it causes me to break out in hives.
In the last decade java finally is starting to catch up!
The latest java releases have finally given us the ability to pass through a function, and work more functional.
And you can choose any GC you want, even less "stop the world" ones, but who got the time to figure out which GC they actually want...
The memory allocation from C is what haunts my dreams more than the GC from java.
Still, I really want to give Rust a look, if only I gave myself enough time.
Sorry, you had a small error in the spacings of your post; Therefore I cannot parse a thing you're saying. Didn't mean to scare you with a semicolon either. It's just a tool in language's to end a clause and begin a related, independent clause. That could be useful somewhere...
An text file with a <script> block and nothing else, containing a console log, is all you need. You already have all the boilerplate to run it in any computer. No extra dependencies, no installing anything. Literally just a notes editor app. This is a valid HTML file:
I don’t particularly like Java, but I use it because it pays the bills. Similarly, I use C++ (which I prefer) when my work requires it.
I mean, anon is not arguing against that. They're saying the language is shit regardless of how much it is used in business. I don't think they are entirely wrong.
This ancient one has learned the art of pragmatism. A little time in the trenches of enterprise development can do that – turn passionate ideals into practical choices.
Some days it’s C++, some days it’s Java, Python and so on. In the end, the code compiles, and the ancient one get paid.
Yup, I swore off Android dev almost entirely because of Java, and then Kotlin came out and Android programming was tolerable again. Not fun, tolerable, lipstick can only make a pig so appealing...
I also think Java is shit, but if you manage to get a NullPointerException while writing a hello world program, maybe anon is just not cut out for computers?
After close to two decades of programming, C# is still the best language I've used. While some of the newer features seem a bit weird, I'd say it's one of the few languages that has never got in the way and has just let me write code that made sense. Even with all the improvements Java has made over the years it's still nowhere near as good as what C# was like maybe 15 years ago.
The same goes for everyone's other "fav" language, Python. Ruby has been a better beginner scripting language than Python for many years, and while Rails is definitely a ghetto, as a language Ruby is great at teaching great programming fundamentals.
C# is pretty good generally - I know it far better than any other and it pays my bills! - but it certainly has its weak points. Particularly around the newer features, a lot of them feel really rushed and just kind of shitty.
The one I hate the most is the whole “nullable” pattern. It’s a total mess. Having to mark up files as #nullable enable, having to mark methods with a bunch of attributes, and the way that it works differently if it’s a value type or a reference type, it’s just so half-baked.
If you spend some time with a more modern language like Rust or Swift then you’ll quickly start to notice C#’s weaknesses.
I feel like you're doing something wrong with the nullables... I'm pretty sure you don't need to mark up files, you can just enable it on the whole project? I'm not sure about the attributes, you might have a point there, but it just makes sense for value vs reference types IMO, since value types are already implicitly different in terms of nullability.
But yeah, I can imagine it's half-baked, since nullable reference types (that's the name, previously reference types were just nullable by default with no extra features) are a more recent addition to the language, one that wasn't built with them in mind.
C# has had string interpolation for, what - nearly a decade, now? It arrived with C# v6, which was released in 2015.
Meanwhile Java just pulled their implementation out of the latest beta earlier this year because they couldn’t get it to work right.
Don’t know about you, but I think that Java is largely resting on its laurels as of late. That the only real reason to go for it is it’s third-party library system, and not much more.
Aside from the general stupidity, Java is a heavily front-loaded language in my experience. I'm not going to engage in any tribalism about it or claim that it's better or worse than others. As a matter of personal taste, I have come to like it, but I had to learn a lot until I reached a level of proficiency where I started considering it usable.
Likewise, there is a level of preparation on the target machines: "Platform-independent" just means you don't have to compile the program itself for different platforms and architectures like you would with C and its kin, as long as the target machines have an appropriate runtime installed.
Libraries and library management is a whole thing in every general-purpose language I've dealt with so far. DSLs get away with including everything domain-specific, but non-specific languages can't possibly cover everything. Again, Java has a steep learning curve for things like Maven - I find it to be powerful for the things I've used it in, but it's a lot to wrap your head around.
It definitely isn't beginner-friendly and I still think my university was wrong to start right into it with the first programming classes. Part of it was the teacher (Technically excellent, didactically atrocious), but it also wasn't a great entry point into programming in general.
I'm not a Java dev, but I know enough of it to fix simple bugs in the backends I work with. My main issue with it is that 99% of the code doesn't seem to do anything. The clear, obvious place that looks like it handles the feature you're looking for? None of it does anything! It just instantiates another class from God knows where to actually do the work. I swear I spend most of my time in Java projects just looking for the damn implementation in a sea of AbstractSingletonFactoryBean shit.
The dev culture certainly contributes to the problem. In the attempt to modularize, isolate functionality from expectations and create reusable code, a mess of abstraction patterns have sprung up.
I get the point: Your logic shouldn't be tightly coupled to your data storage, nor to the presentation, so you can swap out your persistence method without touching your business logic and use the same business logic for multiple frontends. You can reuse parts of your frontend (like some corporate design default structures) for different business apps.
But you can also go overboard with it, and while it's technically a dev culture issue rather than a language one, it practically creates another hurdle to jump if you want to use Java in an enterprise context. And since that hurdle is placed at the summit of the mountain that is Inheritance, Abstraction and Generics... well, like I said, massively front-loaded.
Once you have a decent intuition for it, the sheer ubiquity makes it easier to find your way around other projects built on the same patterns, but getting there can be a confusing slog.
I'm sorry just as a matter of policy I'm going to have to downvote you for saying you like java. Nothing personal.
I think some things that were novel when java came out are such old hat at this point the 1990s benefits just aren't benefits anymore. Run anywhere? I'm in a html app right now. As is my IDE and my chat app. Strong interfaces and sane types are only in comparison to the bizarroland of c++ which visibly always seems to basically be word vomit. JIT compilation is in python which is both easier to use and has way better tooling and libraries...making python today run in the "fast enough" category that java was kinda in. I've literally never seen a usable java UI tho.
So you're going to stride past the part where I say "I'm not going to [...] claim that it's better or worse than others", ignore the bulk of my comment on Java being hard to get into, make a point of declaring you'll downvote for stating a personal opinion, then pretend it's "nothing personal"? I'd be curious how that makes sense in your mind.
Anyway, like I said, I see no point in petty tribalism. I like Python and C too - that's not mutually exclusive. I hope you have a pleasant, Java-less day :)
Python and Java are barely comparable. I adore both languages equally and use them about the same amount at work. They are just different tools better suited to different tasks.
From PIE root "pau-" (few, little), to Latin-transliterated via Greek "paed" (boy, child), and spelled thusly to distinguish from "ped-" (foot), circa 1600AD. Reduced to "pedo" from "paedo" as part of the shift in Americanization of accents and spelling in the late 1700s early 1800s.
Honestly I would consider that a bit weird. At the very least, old-fashioned. If you like Java, it makes me think you haven't tried a better more modern language to compare it with.
It doesn't (usually) come with the Java culture 8 layers of abstraction. This isn't in the Java language. This isn't in OO. Yet nearly every Java programmer makes things way more complicated than it needs to be.
It's a prettier language. Similar syntax with less bullshit.
I only had one job that used C#, and it was the worst job I ever had. Even with the worst possible way to be introduced to the language, I still love it.
Nah, C# suffers from a lot of the same shit Java does. Needing everything to be a class is just no longer a good design choice (if it ever was). AOT support is still lacking. I don't get, why it does not have typdefs. I think the solution / project structure is unnecessary and I could probably think of more stuff I dislike about C#. But imho, it still beats Java.
Golang is my choice over C# any time. I strongly prefer how interfaces are handled and I actually like the error handling.
I like how straight-forward the syntax is. And it also seems orderly to have everything be a class. There's a system to it.
I'm using C++ for a project now and I like it in a similar way, but there's more freedom (everything doesn't HAVE to be a class). So with C++ I'll never go back to Java (unless it's for a job).
I am a certified Java hater, but you're allowed to like it. If simple and objected oriented is what you want, I can see the attraction, and it has a good and mature ecosystem.
The ecosystem is java's biggest asset. C# is actually a pretty decent language to develop in but the ecosystem just pales. Zookeeper for example doesn't have an official client. But one guy ported the Java client but it hasn't been updated in years. Maybe it's recently because I moved on from that job.
No, Java has lots of merits. For example, once you know layout managers, you can have a resizable GUI app in no time. It's the exact opposite of arranging things pixel by pixel. You just define "I want a grid of these buttons south and a big text field in the center" and Java will do the rest. I whip up apps like this for the silliest things, like noting which dungeon has what rotating boss this week in a game, so it's more convinient than noting it in a text file.
They forgot to mention that production Java applications apparently need to log a certain minimum number of completely meaningless stacktraces per hour to work properly. Or at least I assume that is the case from the fact that all of them do that.
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.
wait, so when .io gets deregistered, are a load of companies going to have to rename their root directories and rewrite all of their include statements?
yeah you need main class coz it’s OO-language. Though, not required anymore, which should’ve been done once Java got scrip language capabilities (jshell) back in JDK 9. But as of today not required anymore
imports exist in most if not all languages. Gotta be insane writing them manually in 2010 let alone 2024
installing Java runtime (JRE) is as simple as installing any app. Though for installing JDK you need 5 mins for setting PATH. Think about JDK as like TSC or Webpack and JRE as a Browser. I’d argue installing and configuring JDK is simpler than TSC or Webpack
Unless you doing some non-trivial multi-threading your stack trace will tell you exactly where is your NPE. You gotta be as blind as my teammates to spend more than 1 minutes to find where it is coz it literally tells you file and line numer where Exception occurred
I mean, yeah if you use IDE from 2000 it will look like it. IntelliJ looks modern, though I don’t like the fact latest versions look like VSCode
I hardly reach 3G of deps from all 10 projects I have on my workstation.
IDK what anon means by ecosystem here, Java ecosystem is quite standard across the board. JDK(std lib), Maven/Gradle(deps, build, publishing), Spring Framework (all sorts of blueprints and solutions to standard app level problems), Hibernate/JPA (ORM), JUnit+Mockito (testing). These are tools and libs used in 90% of projects I worked on. Of course there will be more depending on project needs. Layers? It’s not like language imposes any layers whatsoever. It’s just common practice to have 3-4 layers and some glue in-between.
don’t do GUI in Java it sucks and will suck until Java gets string interpolation. Hopefully soon
concurrency is actually the only thing which is really bloated in Java. Which will change with next LTS version if I remember correctly. And it’s not that hard if you actually read the f manual and not just “try and hope”. Again it will become much more efficient and easier to follow soon. As of now - yeah, not trivial. But people mostly prematurely optimize, so karma
Java is kinda have 20 ways to do same thing but actually no. Java built with idea of providing simple building blocks. Then it provides more specific API built on top of those building blocks. It allows to have API which solves typical problems and provides capability to solve custom problems with those building blocks. People often confuse this as many ways to do one thing but it’s like saying “I can have byte array why I need string data type”. Those are different levels of abstraction
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 date of the post is from this week so it’s not accurate at all. Java does support main outside of a class now, and it doesn’t need to be static, or take args. You wouldn’t use JavaFX in this day and age either. Installing the jdk is absolutely nothing especially if you’re using IntelliJ as it will install it for you and manage everything. No library is even close to 3gb.
This entire post sounds like it was written by someone that last touched Java in 2010.
Source: am a Kotlin dev. Java sucks. None of these are the reasons why.
It's not accurate to accuse Anon of "lying," when both their story and yours would point to the race conditions from threads being a symptom of someone who's just learning the language.
It's not that serious though; because it's a greentext, it is both artificial AND homosexual.
Been coding Java for about 15 years now. Pretty much agree - anon’s primary mistake was using javaFX. From a junior dev perspective I can see why they’d do that, but Java isn’t really meant for building desktop applications, it’s meant to power web apps.
What they should have done instead is create a backend restful web service and wire up a frontend rest client with something suited to web app ui dev such as angular or react. Java has some awesome frameworks built for it over the years, something like spring boot would make building that backend service trivial if you know how to use it. JAX-RS/Jersey or even servlets could be utilized for this instead, if you wanted to.
Spring boot has some nice tooling for thread management, but Java also has pretty good options for this built in as well. As chunky mentioned, if you aren’t already versed in concurrency patterns, don’t try to perform concurrent operations or you’re gonna have a bad time. But do learn how to do this, because exploiting concurrency is one of the golden rules of good computing.
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.
On the other hand back in Java 1.2, 1.3 and 1.4 days you frequently had companies install a specific patch level version because their applications worked only with that patch level. That was back when Java was actually popular for some reason.
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.
I mean they are lying because Java does support main as a top level function now. If this was written last year, sure. Also IntelliJ will literally install the jdk and manage it for you. Using asdf I haven’t had to touch the PATH for Java in probably over a decade (used sdkman before that).
This entire post sounds like someone that last touched Java in 2010 and wanted to complain about it again. Java is shit, but for none of the reasons in the post.
Anon pretty much sums up my experience with Java when I had to learn it in college 20-ish years ago. I'll never get rid of my distaste for the language I'm afraid.
Concurrency isn't bad, and package management (while maven is absolutely terrible to work generally), the dependency chains aren't exceptionally bad. Getting it installed is easier than python on platforms it's not already there on, not because it's more portable, but because the installers do more for you. Portability is hard, they haven't done it well but they've paved the default use case pretty well (although that works against you when you get to harder cases)
But the rest is pretty close.
The worst is the scaffolding, it's literally superstition for years to gain the understanding as to why you're doing it. I took two years of Java in high school before getting a degree - it was 4 years and halfway through a degree before I understood why I was making a class with a method main(string[] args). It works like that because your entry class calls the main method with a list of string arguments... I didn't understand at all, because even though it's simple it's a special case, and I'd never seen anyone name the string array anything different, so I just copied and pasted it, never understanding it because I'd been told "you just have to have that" for do long
Builds are arcane too - there's still companies that only use netbeans in their build pipeline, Android still requires a specific an old Java version in conjunction with the IDE or a gradle build, at best a project uses maven (the package manager), which is xml based and full of arcane details that are best treated as a magic incantation to be copied exactly from elsewhere
Anon is absolutely exaggerating for comic effect. That doesn't mean Java doesn't have all of those problems though, it just isn't as ridiculous as they made it out unless you get dragged into enterprise bullshit (then you're in for it).
For the “simple” apps anon is talking about, they are exaggerating a lot. Though, when you get beyond the obligatory “Hello World” and “a window with a button”, the complexity does start to increase exponentially.
Throwing in frameworks like Spring or JavaFX does make things more complicated. But it’s still relatively manageable once you get used to it and know what goes where and when.
Now the whole configuration thing, that’s an art form best left to those hooded “seniors”. It’s good to learn eventually, but not when you first start out; lest you have a fetish for pain.
Java has come a long way. It’s not the languages fault that people create monstrosities like AbstractJavaFinalSerializedFactory or whatever. But if you do want to be “good” at Java, you will want to learn about design patterns. It also doesn’t hurt to have a thick skin too, because you’ll be both criticized and made fun of for your choices. 😊
If you've never used Eclipse, which I assume it was referencing, it does feel old, clunky, and ugly out-of-the-box (to me at least). I tried to use IntelliJ wherever possible, but a previous company had a project that really didn't like to run from it but would with a very specific setup in Eclipse (I don't recall any details now more than 10 years later).
There is a fair bit of boilerplate and bloat.
I don't remember UI stuff being so bad, but most of what I worked with was old Swing/AWT stuff. I did have to use JavaFX (I think it was?) once and remember something about it being frustrating, but it was for some existing thing I had to modify.
I don't mind Java so much, but it's certainly not my favorite language.
I don't know how one gets a nullPointer when doing a hello world, though. I'm guessing this is embellishment or mashing together something later with their initial printing of hello since I think you'd come up with some other error in that process to getting something to print before nullPointer.
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
Idk. Maybe it's because I learned OOP first that it makes more sense to me; but OOP is a good way to break down complex problems and encapsulate them into easily understable modules. Languages like Java almost force everyone on the project to use similar paradigms and styles, so it's easier for everyone to understand the code base. Whenever I've worked on large non-OOP projects, it was a hard-to-maintain mess. I've never worked on projects such as the Linux kernel, and I'm hoping it's not an unmaintainable mess, so I'm pretty sure it's possible to not use OOP on large projects and still be maintainable. I am curious if they still use OOP concepts, even though they are not using strictly OOP.
I also like procedural python for quick small scripts. And although Rust isn't strictly OOP, it obviously borrows heavily from it. Haskell is neat, but I haven't used it enough to be proficient or develop good sense of application architecture.
I've done production work in C, but still used largely OOP concepts; and the code looks much different than code I've seen that was written before C++ was popular.
The Linux kernel actually uses quite a bit of OOP ideas. You have modules that are supposed to have a clear interface with the rest of the world, and they (ab)use structs to basically work like objects. If you try hard enough, you can even do "inheritance" with them, like with their struct kobject. It is actually somewhat well-thought-out, imo. No need to go full OOP, just pick some of the good parts, and avoid the MappingModelFactoryServiceImpl hell or the madness that is C++.
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?
Stuff like enemies, bullets, loot, items, etc. are constantly changing and affecting each other. This makes it difficult to program in fixed functions that run through and crosscheck a bunch of constantly changing arrays.
It makes logical sense to have objects with their own functions stored in dynamic lists instead of arrays.
A lot of the properties are used by several different objecs, like coordinates or health points, so it also makes sense to describe them in classes.
So, I'd say that it's a useful way to classify data that is very dynamic, or when different functions need to run depending on that data.
I don't like putting all code into classes, because a lot of code doesn't need that kind of flexibility.
What are some common situations where using an object is a good solution?
It depends on what you mean by "object"
Some kind of structured data?
Some named type which fulfills an interface?
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.
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.
I started with java for school. The day I tried C for the first time I was flabbergasted, "what do you mean it doesn't matter which order I put things in?"
I'll never get the hate for java and love for python. It's like learning mandarin because you think it's easier than Spanish. When you know java you also kinda know javascript, C, Php, and others. When you know python, it's probably a government sponsored course, or a programming class talked your school district into buying their "intro to programming python course". Plus you only get to know python. I'll die on this hill
In my experience, this kind of sentiment is what marks someone as a seasoned professional. When you finally see that all tools are flawed and deserving of some negative remark for a bone-headed misfeature or three, you've arrived. Carry on.