This question originally appeared on Quora: Why do many software engineers not like Java?

Answer by Michael O Church, functional programmer and machine learning engineer, onQuora

First, let’s cover the technical issues. It’s verbose, combines the worst of both worlds between static and dynamic typing by having a hobbled but extremely clunky type system, and mandates running on a VM that has a macroscopic startup time (not an issue for long-running servers, but painful for command-line applications). While it performs pretty well nowadays, it still isn’t competitive with C or C++ and, with a little love, Haskell and OCaml can or will eclipse it in that domain. For real-world production servers, it tends to require a fair amount of JVM tuning.

The VM itself has a lot to recommend it. It offers concurrency and garbage collection at a level of quality that, until recently, wasn’t found anywhere else. Python may have a better user experience, but it also has a GIL, which rules out parallelism. Much 

important software in the early 2000s was written in Java because, at the time, it was the best choice, even taking the mediocrity of the language itself into account. It had Unicode (albeit, UTF-16) from the start and a strong concurrency story, and it was a notch above C++ in terms of user experience (because, really, who wants to debug template errors deep in someone else’s legacy code?)

If you put Java on a technical trial, it doesn’t do so bad. The language sucks, the platform is pretty good for most purposes. I do hate the dominant interpretation of “object-oriented programming” with a passion, because it objectively sucks. See: Michael O. Church’s answer to Was object-oriented programming a failure?

So let’s talk about the political and cultural issues. First, the dominant Java culture is one of mediocrity and bad taste, with MetaModelVibratorVisitorFactory classes dominating. I’ve heard a number of experts on “the Java issue” argue that Java’s biggest problem is the community, and that comes directly from the fact that good programmers don’t want to deal with the bastardization of OOP that has entrenched itself in mainstream corporate development. You have a lot of people who trained up as “Java programmers”, haven’t seen a command line ever, and have no clue how the computer actually works. Most of them have never actually written aprogram; they just write classes and some Senior Chief Architect (who makes $246,001 per year and hasn’t written a line of code since the 1990s) figures out 

how the computer actually works. Most of them have never actually written aprogram; they just write classes and some Senior Chief Architect (who makes $246,001 per year and hasn’t written a line of code since the 1990s) figures out how to stitch them together, and then tells some other clueless junior how to implement the glue in the gutshot hope that one will actually have the talent to make an actual working program out of the mess.

This isn’t inherent to the JVM, because Clojure (currently hosted on the JVM, although its endgame seems to be language-agnosticism) has a radically different (and better) community. Scala’s community is more mixed, but the top Scala engineers (the ones making tools like Spark and Kestrel) are really freaking good.

The root problem, lying under all of this, is that God clearly intended for the programmer-to-program ratio to be one-to-many. It’s much more productive and engaging to work that way. Programs should be small, and when you need a lot of code to solve a large problem, you should create a system and give it the respect that systems of code to solve a large problem, you should create a system and give it the respect that systems deserve. The vision that seems ensconced in the modern Java community is one of Big Programs where the programmer-to-program ratio is many-to-one. I’ve written at length about why this leads inexorably to political behavior and low productivity: Java Shop Politics.