Hacker News Reader

Comment by acdha | Hacker News Reader

> - you can integrate code from hundreds of developers fairly safely (knowing that no one has changed the default behaviour fo builtins and different dependencies won't clash).

It's exceedingly rare for this to be untrue of Python — it's technically possible to hack builtins but there's intense community pressure against doing that.

> - the syntax, although not the most succinct is fairly easily readable and maintainable by other developers.

This is sort of true but it misses the aspect which makes Java hard to maintain: the language being less capable means that you end up with more boilerplate syntax which has to be understood when reading it and the patterns that produces tend to be the long-term maintenance issue instead.

View on HN

> This is sort of true but it misses the aspect which makes Java hard to maintain

The boilerplate syntax you talk about comes from like java 1.4.

Modern Java is quite expressive with streams and lambdas. If one does employ the Java Beans convention than yeah, he/she has to autogenerate a few getters setters, but those don’t occlude the actual logic.

And frankly, empirically, Java is anything but hard to maintain. You would be hard pressed to find many languages that continue to manage at the scale Java apps routinely handle.

Yeah, it’s (typical business monstrosity) hard to understand, probably has many thousands hours of technical debt, but it just works, and more things can be added to it (and occasionally with much more work, removed as well).

> The boilerplate syntax you talk about comes from like java 1.4.

I was thinking about things I've recently seen in new Java 15 code, so no. There are lots of old APIs in the Java language and popular libraries, and while things like streams are quite powerful, they're far from universal. I still see developers cranking out code which has to do what is built-in in other languages.

As a simple example, not having multiple return means that you end up with worse APIs in some cases or small classes which exist to wrap a couple of things — not necessarily terrible but it means that you've just taken on maintenance work for something which would be trivial in other languages. That extra code isn't exactly a huge lift but when you add things like that up regularly it's not hard to understand why all of the good Java developers I know are keenly following things like Kotlin which give more expressiveness without giving up all of their familiar tools.

Yeah, multiple returns does come up from time to time, but nowadays with records you at least have named tuples in with one line declarations. And if you don’t save the return type, I’m sure the escape analysis will get what you are doing, so it won’t be heap allocated.

But I do agree that there is space for improvements here.

It's true that Python programmers don't often hack builtins, but they still do things which aren't possible in Java.

For example: imports inside functions instead of at the top of the file (because the import does work, but the configuration hasn't been set up yet).

An example of this is an internal package at my workplace which makes a external service request at import time.

I felt literal pain reading this.

Reply on news.ycombinator.com