[vkazanov]

It is not "an interesting opinion". It is an opinion of a mid-level engineering manager who spent the last decade hiring and building teams across various parts of the industry.

Java/JVM is literally everywhere. And let me get this clear: not a fan of both java-the-language and java-the-culture.

[Joel_Mckay]

Interesting perspective, the exact same argument was made for COBOL and Fortran.

Most Enterprise level Java I saw was not clean OOP, but rather a heinous kludge sitting next to a half-baked design pattern. The 3.6B Android OS users in the world probably are more relevant in terms of development projects, and keeping your team staffed. Good luck =3

[vkazanov]

I am not speaking of some legacy systems, java is THE language right now, the same way Fortran was the only one in the first couple of decades of existance.

Besides, what is "clean OOP" even?

[Joel_Mckay]

In my opinion, ideally a well-planned/templated object structure focused around well documented design-patterns without bodged-on/polyglot binary objects.

Thus, people that actually leveraged the OO paradigm properly, and in a way that may be sustainably regression-tested/maintained over many continuous integration cycles. That kind of "clean" code tree usually only needs juniors to study around <5 files to understand even the most complex modules operation, helps mitigate bugs, and team-leads can weed out quality "issues" in minutes.

People that churn teams usually discover a YOLO and OO paradigm are fundamentally incompatible concepts. People won't know everything they need in the first release, and they will have stuff they don't need but now have to live with by the third release.

This is not a Java specific problem... but it does make it easy.

Nothing integration "teams" do will likely matter much compared to a 3.6B user-base policy change. Have a great day =3

"Nor would a wise man, seeing that he was in a hole, go to work and blindly dig it deeper..." ( The Washington Post dated 25 October 1911 )