Hacker News Reader

Comment by thayne | Hacker News Reader

> Java isn't that terrible of a language

True. It isn't a great language, but isn't terrible. What is terrible are the over-engineered, over-abstracted APIs that are relatively common in the Java ecosystem.

View on HN

What I hate is that I can't understand anything when I try to understand existing code with all the abstractions going on and having to jump through 100s of files with so much boilerplate and clutter, trying to understand how the logic binds together. And then just interfaces everywhere, I can't even jump with an IDE, I have to find where this interface magically gets injected first to find the actual logic.

Also I guess I don't like massive slow IDEs and slow compilation times. I just feel so slow when working with Java as well my mind gets distracted and frustrated. Maybe it is my personality flaw to not have that type of patience.

Structured programming saved us from “spaghetti code” but Java culture introduced “spaghetti class hierarchy” and practitioners seem to practice it quite religiously.

This was probably the one bit that I really disagreed with. I've never been a Java developer, but I've had to touch it a few times in my career, and have quite happily left very well paying jobs for lower paying jobs just to avoid having to write more Java. I can't rightly think of any language I would plausibly have to use in industry that I find more unpleasant than the Java and the entire JVM ecosystem (disclaimer: I've never used PHP).

I'll buy that Java might, in purely technical terms, be not that terrible of a stack, but it's just so deeply unpleasant to use, such a profoundly nightmarish vampire of morality, so utterly and irredeemably cruel in it's ability to strip all joy out of the art of software development, that I can't possibly agree that it "isn't that terrible of a language".

Did you know that Java lets you any number of module scoped classes in a single file, just that the public class has to have the same name as the file? There are a lot of things like that you can do in Java which people just don't do that makes many things a lot cleaner. Its just that the eco system standards were set by people who thought that having unique class names were super important even though Java already have namespacing.

Also that you need to have 100% super guaranteed unique global namespaces making your folder structure that horrible net.xxx.abc.adsasd.dfer.cthulu.NetXxxAbcAdsasdUtilityHelperBuilderFactory things, which for some reason wasn't needed in any other programming language and it worked just fine for them so you don't need that either.

With that instead of importing stuff you could just write something like, assuming each library have a sensible top level name:

    gzip.File g = gzip.File.FromDirectory(dir);

When I write Java personally it looks closer to that. And when I follow a corporate style I write it more like that, as close as possible while still following the style guide. I 100% believe Java could have been a nice experience if it didn't have its horrible over engineered style guides.

> There are a lot of things like that you can do in Java which people just don't do that makes many things a lot cleaner.

The problem is not "people could use that particular Java feature to make code cleaner, but they don't".

The problem is on a higher-level: If you have ever tried to read your way through some library, e.g. Spring, you'll see code spread over hundreds of files, and it takes ages to just find out where that particular bit of code you need is, because it's automatically injected in some builder class which is an inner object extending some other object that implements an interface somewhere.

And then you have several competing abstractions, and sometimes one gets used, and sometimes the other.

IDEs and type hierarchies help, but only to some degree.

And then you are still stuck with an overengineered abstraction that nevertheless does not allow you to do the obvious thing that needs to be done in your particular case. So you need to implement a fragile workaround, for example copying one of the library classes, modifying it a bit, and then injecting it instead of the one from the framework. All of which will horribly break if someone changes something in the library.

"Style" is never the problem.

> The problem is on a higher-level: If you have ever tried to read your way through some library, e.g. Spring, you'll see code spread over hundreds of files, and it takes ages to just find out where that particular bit of code you need is, because it's automatically injected in some builder class which is an inner object extending some other object that implements an interface somewhere.

There is nothing about Java the language which forces code to be written this way though.

>deeply unpleasant to use, such a profoundly nightmarish vampire of morality, so utterly and irredeemably cruel in it's ability to strip all joy out of the art of software development...

Oh my...

As a Java developer, I'm curious. Can you elaborate a bit? Was this some really old version of Java, a horrible IDE, crazy frameworks, something else? Am I living in a nightmare and just haven't woken up yet?

I realize that performance has been an issue in the past, but that has been solved. I've used plenty of other languages (also functional ones), and they all have their quirks. In what ways is Java perceived to be worse than other languages nowadays?

I’m sure a lot of it comes down to taste and personal preference, but for me everything about java is just very high friction. I find the docs and standard library deeply unintuitive and hard to navigate, the language itself feels verbose, inflexible, and the spec for the language is very large and complex. The type system is inexpressive and overly limited. The applications themselves, by virtue of the jvm, feel deeply disconnected from the underlying system. I don’t like the fact that Java seems to assume I’m going to use an ide with auto complete and refactoring.

I’ve used a lot of languages professionally in my career: C, C++, Go, Perl, python, ruby, JavaScript, typescript, Erlang, Haskell, Rust, some Kotlin and Java. There are some languages I quite like working with (Haskell, C, Go) and languages I can use just fine but I’m not that fond of (python, JavaScript) and plenty of stuff in the middle, but nothing that makes me want to just walks away from the computer in disgust like the JVM languages.

Edit: a final though.

Really, our industry is pretty new and we’ve made a lot of mistakes. All of our languages have warts and deep flaws. Happiness in your career isn’t about finding something perfect, it’s about figuring out which flaws you can live with and which ones you can’t. I could go on about technical reasons but at the end of the day the JVM is just full of flaws I can’t just live with, and for whatever reason I’ve talked to a lot of other developers who feel the same way, and many who don’t.

Interesting points, and I have to say they do ring true. The type system is definitely limited and if you compare it to Haskell I understand 100% why you'd be frustrated. And the docs are overly verbose while simultaneously not being detailed enough.

For me, I'm currently at a point where a lot of these things are „known issues“, and they don't affect my day-to-day too much. I think the last time they did matter was during the Java 1.7 -> 8 switch, but I see what you mean.

It's funny that you mention not being fond of Python & Javascript, because those are the two most "mainstream" alternatives I thought you'd compare Java to, with plenty of warts themselves.

In my 15 years of professional work I spent 2 years having to use Java with GWT framework and it was the most horrible, deprived of any joy, experience in my career that left me completely burned out and since then I absolutely hate Java and anything related to it.

Reply on news.ycombinator.com