OMG, Java is so verbose, guys | Hacker News Reader

OMG, Java is so verbose, guys

medium.com

12 pointsPleaseHelpMe17 comments

But Java is objectively verbose. The amount of milliseconds it takes someone to type a semicolon is pretty irrelevant to the inelegance of the language itself and how it is used. Author seems to be going on a rant defending Java more than anything else IMO.

He covers type inference too, which is much more painful not having:

Animal animal = new Animal();

val animal = Animal();

Swift also doesn't need the semicolons. You can also omit the () in if and switch statements. It all adds up to a lot unnecessary noise. The immutability of let is really nice too.

let animal = Animal()

In Swift I don't bother adding the type for Strings, Bools or Ints:

let foo = "Hello world"

let answer = 42

var isDone = false

if isDone {

  print("Correct: \(answer)")

} else {

  print("Wrong answer!")

}

> But Java is objectively verbose.

So what?

> Author seems to be going on a rant defending Java more than anything else IMO.

Also known as "a breath of fresh air" :-)

Edit: on a more serious note I find Java to be completely worth it as long as I make simple webapps and do simple backend tasks (payment and messaging integration).

> So what?

Exactly! I don't necessarily consider this a problem as much as something that "just is".

Focusing on semi-colons is a distraction.

There are two core problems w/ Java:

- It doesn't support local type inference. Supporting this would clean up a ton of java code with unnecessary type annotations while still keeping signatures explicit and making refactoring tools, code completion, etc. (a strength in the java world) working properly

- The culture of java library design is one where the entire domain of the problem is surfaced to the end user, typically in the form of a complex object model. This means to accomplish anything you often need to write some fairly complex code dealing with concepts you aren't particularly interested in.

My theory on the second problem is that java's type system and code completion allowed very complex libraries to work well enough, and the culture of java development (OO, highly technical) encouraged them. Meanwhile in the dynamic world, with no-or-shitty code completion and a focus on getting things done, darwinian selection weeded out libraries with verbose APIs.

Please don't write articles in this kind of tone. It's pure self-sabotage, guaranteeing that you'll only be preaching to the choir.

I submit the link. I didn't write it.

We however do enjoy it!

My main gripe with Java is its lack of type inference and the resulting redundancy that pops up. Things like the following got tiresome quickly (I might be a newb missing out on a better way to do things like this)

  private final TreeMap<String, TreeMap<String, Record>> searchTree = new TreeMap<String, TreeMap<String, Record>>();

FWIW This will raise a warning in my dev environment as I have declared in my pom file that I use JDK 8.

Also I'd consider it better style to only specify the interface on the left hand side, something like this should work:

private final Map<String, Map<String, Record>> searchTree = new TreeMap<>();

Edit: if you use Netbeans with maven it will automatically pick up correct settings from the pom and autocomplete with a shorter version like the one I suggested.

This is a much more reasonable example than the line used in the article.

I'll be honest, semicolons aren't the first thing that pops into my head when someone mentions Java's verbosity.

Yeah, it strikes me as really odd to write an entire article where the main focus is semicolon 'verbosity'.

Kind of a muddled message... I am an Android developer and while I don't _love_ Java, I don't _hate_ it either. But to say it isn't verbose... well I don't know, it definitely seems verbose to me.

I feel like the author set up a straw man so he could knock it down. But buried inside is a message that I think is important: "use the tools that make sense for your specific situation".

I started developing a new Android app just under a year ago. From day one the client had a release date in mind. Sure, I could have come up with a million reasons to use Kotlin instead of Java. I could have justified using Kotlin to myself and my client would have trusted my decision. At the end of the day though, I had no experience with Kotlin and could not confidently commit to the proposed timeline if I used it.

So I went with Java. Everyday I read articles about the cool things happening with Kotlin. I'm definitely curious about it and I hope to try it out at some point. But I don't regret using Java.

With all that in mind, I feel like the general weirdness of the Android SDK and the fragmentation issue are far bigger problems in the Android world. I don't see any particular language choice solving this problem. I also don't think there is much that Android App Developers can do to fix this issue. I think it comes down to what Google wants to do to fix it, until then developers can only build ways around these deficiencies. Maybe this helplessness is why we see so much noise about different languages/frameworks/patterns/etc in the Android world.

I love Java. It's a bit verbose. I love Kotlin. It's a lot less verbose.

Java has been my go-to language for a while. After taking 3-4 days to learn Kotlin earlier this year, I'm thinking my default is gonna be to use Kotlin. It's very nice.

Just try static imports, then you can write Java that looks like python

Why static imports are not used in most programs? Any gotchas or disadvantages to it?

Reply on news.ycombinator.com