But that's the whole point of JAVA. It's an opinionated platform with a hyper-standardized workflow. Sure, that limits creativity, but in many business contexts, the last thing you want is your programmers getting "cute".
There's a straight line from requirements to implementation; no meandering involved. At least that's the theory. In practice...
> But that's the whole point of JAVA. It's an opinionated platform with a hyper-standardized workflow.
That may have been where Java wanted to go, but, when I'm working in Java, I don't feel like that's where I am. Ways of doing things in Java tend to be wildly inconsistent from project to project. Partially, I think, because so much core functionality in the Java ecosystem was allowed to be federated out to 3rd-party projects for so long. Take the long-standing popularity (and rivalry) of Guava and Apache Commons for handling even basic tasks that are hard to get done using the core Java APIs. If there's such a thing as a "platform smell", I'd say that certainly qualifies.
With Python, on the other hand, there is a fairly consistent common understanding of what "Pythonic" means, and, even when there really is more than one way to do it, the question of which one to use can usually be quickly resolved to a predictable outcome by simply pointing out that one option is the more Pythonic way to do things.
(edit: Though, to be fair, Java was first released into a world where languages like C, C++ and Common Lisp represented the status quo. Expectations were lower at the time.)
It's definitely gotten better over the past 5 or so years. But there was a lot of time spent acquiring technical debt over the preceding couple decades.
Even if I don't use Guava or Apache Commons myself, for example, I still occasionally run into dependency conflicts that I need to resolve with awful hacks like package relocation because so many other major libraries rely on one or the other, and neither library is a particularly great citizen about breaking changes.
It’s interesting - when you begin adding constraints, sometimes it helps solve the problem. You can’t be creative unless you’ve created a solution. It would be interesting to see the impact on this with programming languages.
When faced with complexity you have to use with whatever 'opinionated hyper-standardized workflow' to build 'un-opinionated hyper-unstandardized workflows'. The net result is like trying to build sculpture with glass with chisel and hammer.
Its then you realize you had better started with clay.
Yes. That may very well be. And I'm not saying Java is bad because of what I described. Just that I experience the, "ugh OOP isn't helping me do what I want to do here" with Java.
According to my experience "enterprise problems" are more related to scalability, data integrity, APIs, and workforce hiring than "what programming paradigm to use."
There's a straight line from requirements to implementation; no meandering involved. At least that's the theory. In practice...