4 ms·

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

by Chabs 8y ago

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

Waterluvian 8y ago
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.
- std_throwawayay 8y ago
  It probably is the right tool if you have an enterprise problem that needs an enterprise solution.
  - mikmoila 8y ago
    According to my experience "enterprise problems" are more related to scalability, data integrity, APIs, and workforce hiring than "what programming paradigm to use."
xapata 8y ago
It was a hypothesis, not a theory. Usually a hypothesis is abandoned after so many counter examples.
madmax96 8y ago
https://medium.com/stanford-d-school/want-some-creativity-crank-up-the-constraints-5728a988a635 https://medium.com/stanford-d-school/want-some-creativity-cr... 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.
jcoffland 8y ago
I'm glad I don't work places that try to keep me from being "cute".
bunderbunder 8y ago
> 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.)
- deleted 8y ago
  [deleted]
- mikmoila 8y ago
  To be honest, I've never seen a problem I couldn't solve in easier way with core modern JDK libraries than with "3rd party" libraries.
  - bunderbunder 8y ago
    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.
kamaal 8y ago
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.

by Chabs 8y ago

Waterluvian 8y ago

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.

std_throwawayay 8y ago
It probably is the right tool if you have an enterprise problem that needs an enterprise solution.
- mikmoila 8y ago
  According to my experience "enterprise problems" are more related to scalability, data integrity, APIs, and workforce hiring than "what programming paradigm to use."

xapata 8y ago

It was a hypothesis, not a theory. Usually a hypothesis is abandoned after so many counter examples.

madmax96 8y ago

https://medium.com/stanford-d-school/want-some-creativity-crank-up-the-constraints-5728a988a635 https://medium.com/stanford-d-school/want-some-creativity-cr... 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.

jcoffland 8y ago

I'm glad I don't work places that try to keep me from being "cute".

bunderbunder 8y ago

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

deleted 8y ago
[deleted]
mikmoila 8y ago
To be honest, I've never seen a problem I couldn't solve in easier way with core modern JDK libraries than with "3rd party" libraries.
- bunderbunder 8y ago
  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.

kamaal 8y ago

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.