[btilly]

And so we have a chicken and egg problem.

Thanks to verbosity, Java creates the very problem that it tries to help with.

Did you need to have that many programmers and that much code? Who knows. But once you have it, continuing with Java makes sense.

[twblalock]

Verbosity is not a problem. The problem is being able to navigate and understand a large codebase. Terseness and dynamic typing are the enemy of that goal.

[btilly]

Attempts I've seen to quantify it have found that you hit a productivity peak in a team of 5-8 people. Then you need to add processes to avoid n^2 communication overhead. You don't get back to the same productivity until you have a team of 20-25 people.

If you've never worked on a small team, the productivity difference from staying small may not sink in. But they are real and large. And companies should not lightly cross that threshold.

I agree with you that, on a large team and in a large organization, terseness and dynamic typing are bad. But I don't agree that verbosity is not a problem. It absolutely is. It makes you have to go to large teams sooner.

[kaba0]

Why is that verbosity never mentioned as a negative for Go, when in fact, Go is more verbose than Java?

Also, I really have a hard time believing that java would be significantly longer than any other mainstream language, it is at most longer by a small constant amount.

[dragonwriter]

> Why is that verbosity never mentioned as a negative for Go

It is, all the time. For some random examples:

https://news.ycombinator.com/item?id=27175184

https://news.ycombinator.com/item?id=8893204

https://news.ycombinator.com/item?id=19354659

https://news.ycombinator.com/item?id=33942901

[invalidname]

Modern Java isn't remotely as verbose at scale. The language is very different and the API+3rd party support is so vast you can usually build huge things with very little code.

[btilly]

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.

[invalidname]

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.

[ghostwriter]

> 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.

[kaba0]

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