Why Software Engineers Hate Java

images (2).jpg

 

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.

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 a program; 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 f***ing 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 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.

At the heart of the failed, ugly, corporate bastardization of “object-oriented programming” is an evil vision of the commoditization of programming talent. If you don’t see that as an enemy worth all-out war, you’re either not human or not decent. Of course, none of that is Java’s fault, at all, really. Java was designed for embedded systems in the mid-1990s, and the mediocritization of software came later.

So, the short answer is: it’s mostly not about the underlying platform (which is generally of high quality) and its only partly about the language (which is mediocre but can’t be blamed directly for community problems). It goes a lot deeper than that, and not all of it is Java’s fault. However, Java takes its share of the blame for its clear favoritism toward large programs (technically, established by its long startup time) and by its support of a very ugly (and counterproductive) variety of object-oriented programming.

 

Source : http://www.huffingtonpost.com/quora/why-do-so-many-software-e_b_6833206.html

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s