Well, there are lots of people out there who view "Pythonic" as a euphemism for awful tbh. Throughout my career I've seen multiple large Python codebases be rewritten in Java after they turned into a mess, including - perhaps most embarrassingly - Google's internal code review tool Mondrian, which was written by Guido van Rossum himself.

One reason Java codebases feel more abstract is that they're attempting to solve problems that the scripting worlds tend to just punt on, or handle in ways that don't scale well. And because Java's type system is nominal, solutions to those problems require names.

For example, a lot of the abstraction in Java codebases is to make things deeply testable. That's what drives dependency injection, which is where a lot of BeanFactory stuff comes from. What's the Python solution to that problem? Often they just hardly have tests by the standard of Java developers! This is why Python is big in ML research where codebases are often small disposable experiments, and why after a brief era where Django was popular it sort of died off in the wider server / big data space.

Another source of complexity and abstraction is a focus on pluggable ecosystems. Databases are abstracted by JDBC, and then again by an ORM, which then might be abstracted again by Micronaut or Spring, and at each layer there are multiple competing implementations available which implement standard APIs. This kind of thing happens much less in the scripting world. The downside is that scripting codebases are far more locked-in to their choice of libraries. Porting a Java codebase from one database or ORM to another is hugely easier, because the core APIs are all standardized.

It's a culture, not language thing. Here is a JSON parser implementation (part of PlantUML) that lacks endless levels of abstraction.

https://github.com/plantuml/plantuml/blob/master/src/main/ja...

Those are not Java paradigms per se - they're just practices of mediocre enterprise developers, of which Java has many, owing to being such a mainstream platform.

As for the language itself, a lot of verbosity has been culled in later language versions, with diamond operators, lambda expressions, local variable type inference, etc.

In either case, code is read more than it is written, so if a bit of verbosity makes code easier to read, I'm okay with it.

As others are saying, it's a culture not the language. C++ and even some Python etc written in the late 90s, 00s era has the same pattern-itis. It comes from slavish adherence to the Gang Of Four patterns books and an obsession with OO generally. Also the languages themselves were weak on non-OO abstractions and ways of doing code re-use, so for example it took forever for Java to get lambda expressions ... so people used one-off helper classes with "invoke" methods, etc.

ThingDoer.doThing was often just functional programming squeezed into an object-oriented straightjacket. Java 8 added first-class functions and lambdas over a decade ago, eliminating a lot of the need to turn simple behavior into full-blown classes.

One reason for that Java style is that Java was not such a powerful language for a long time. For example lambda expressions were only introduced in Java 8 (2014) and before that developers need to work around this restriction. A common workaround were/are some annotations above of methods and some reflection magic on top. For example a life cycle callback method annotated with @PrePersist is basically the same a registering a _function_. The whole Lombok library is a massive hack to circumvent some inconveniences in Java (and in my opinion no longer needed).

I think a lot of it is the people using it and certain parts of the culture. There are a lot of Enterprise TM programmers that seem to believe as many layers of abstraction and as much verbosity as possible with little tiny methods that do practically nothing leads to better solutions. It is totally possible to write concise and pragmatic code with Java. One thing that will be a thorn in your side though is null handling. The traditional approaches increase line count and branching. The newer(ish) Optional-based null handling is quite verbose but in width.

I think it doesn't have to be like that, but it's the way Java code has been written for ages, so those habits stuck. You can see it clearly when you bring a Java programmer to collaborate on a Ruby or Python codebase, if you let them, the will turn your codebase into an enterprise-ready mess with layers on top of layers of indirection in a blink.

> by-product of Java's strict type system

1. Lack of first class functions till Java 8 is one reason old APIs are horrible with inheritance and reflection everywhere. You had to extend class and override methods even for simplest of tasks.

After Java 11 the code is much more succinct and functional style. But old libraries remain.

There are places where the overextensibility these libraries provide is useful. But those are few.

2. the annotation processors were late to the game - so many libraries which need to inspect object structure (such as serialization) were written with heavy use of reflection.

I will give you an example of how frameworks designed for "modern" Java look like.

Micronaut has something called Micronaut data JDBC - in which you just declare methods with few annotations eg `List<Book> queryTop10BooksByYear(int year)` and it will auto generate the JDBC + SQL code and handle injecting it into your service. The returned object can be a POJO without all the Proxy object circus ORMs come with. I haven't seen something as easy in Python yet. And all this happens in compile time with an annotation processor.

As someone who has seen awful code in pretty much every language I've worked with, I'd blame this more on inertia and reluctance to change habits. The bad patterns that have entrenched deep into the ecosystem are very hard to shed even when the language and platform is making progress at impressive speed.

As other sibling comments have said, it's cultural. Fortunately, there's some push toward functional & ADT-style modelling in the Java community and they've decided to call it "data-oriented programming" for some reason.

Eh, I don't think Java type system is strict, nor is it the root cause of this cargo cult mess. It's probably due to many enterprise programmers who think design patterns are the building blocks of everything rather than an invisible, emergent structure.