Hacker News new | ask | show | jobs
by btilly 1280 days ago
20 years ago, the rule was that Java took an average of 10x as much code to say the same thing as a scripting language did.

In all the time since I keep hearing "modern Java this" and "modern Java that". But every time I venture into some Java, well, my limited experiences haven't fit what I was told about "modern Java".

Maybe I just haven't encountered modern Java?

As for the API+3rd party support argument, the productivity of third party libraries has been used as an argument for ages. I remember when it was being made about Perl with CPAN. My experience of it has always been that libraries make a great start to the extent you have a common problem. Which is wonderful for demos. But once you're in the weeds, you still have to write lots of code. Maybe there isn't a library for your unique needs. Maybe the standard library has bugs. Maybe you wrote code because there wasn't a library but now there is.

No matter how it comes about, you wind up writing code.

2 comments

20x was always an exaggeration. It counted class boilerplate and compared stuff like hello world which was always "decorated". As scale that overhead gets minimized. Java will always be a bit more verbose than some other languages. It's strict. By definition that's more verbose. It also forces declarations (e.g. public). Again, a choice to keep things clear.

But that's not the code that takes time to write or read. In that department Java isn't more verbose in a significant amount. If you're the type of person that gets upset that every line ends with a semicolon or that we need to repeat the word public for many methods. Then sure. Java is verbose.

Looking at the body of a Java method I don't see something I can significantly cut down with TypeScript or Python.

> Maybe I just haven't encountered modern Java?

even modern Java 18 codebases with exclusive use of records instead of classes, and with enabled enhanced support for instance pattern-matching instead of old-school conditional blocks and switches, are still significantly more verbose than Scala codebases, especially if the latter use `cats` or `scalaz` for all traversal/mapping/folding logic. Java developers would just manually encode all these patterns into series of nested loops by hand by default every time, because the required tooling as well as the compiler help to aid that tooling is not available in the language.

Mapping/folding is possible with plain old java streams. So while scala can be smaller, the difference is not too significant in my opinion.