Stop hating Java | Hacker News Reader

Stop hating Java

andrzejonsoftware.blogspot.com

115 pointssnatcher151 comments

I think a lot of the Java hate is because of the architecture astronauts who hijacked the language in the last decade - J2EE/EJB, the GoF, FactoryFactoryFactory shit and so on. I remember seeing the earlier versions of the servlet API and it was very elegant and well designed; unfortunately once the astronauts were through with it writing Java web apps became such a form of mental torture (Struts, anyone?) that even PHP was a welcome relief, let alone Rails. My hate for it came from having to use some shitty app server like WebSphere because the coding-averse CTO considered it a "standard".

Looking at more recent work such as the lovely Play framework and the influence of new JVM languages such as Clojure and Scala, it looks like things are improving in Java-land. It's still a bit dated and clunky compared to Ruby and Python (let alone Clojure/Scala or even Groovy) but it's not as bad as people make out.

... architecture astronauts who hijacked the language in the last decade - J2EE/EJB, the GoF ...

Thank you for writing this. When I first read the GoF Design Pattern Book I thought "this is the reason, why the code in my project is bloated, unmaintainable and shitty".

I do think GoF has it's place, and every serious programmer should be familiar with it; if only to know what to avoid.

[edit] I didn't mean to sound so negative about GoF. Know the patterns so you know when to use them, and when to avoid them. You can't debate these decisions when you're ignorant of design principals and history.

You are right. The GoF only promoted bloated code. Who in their right mind would use patterns like the Observer, the Adapter, or the Visitor?</sarcasm>

Not sure if you know the history, but the authors of the book really only collected the patterns that they had seen around them in Smalltalk and C++ code. They wrote a catalog so we could all refer to the same name instead of using different names for the same concept. They identified the common problems that these patterns tried to solve and they also identified the trade-offs. Oh yes, they identified trade-offs!

Unfortunately, many developers thought that they had to put as many patterns as possible in their code, which was not the intent of the GoF. Ralph Johnson said that they received emails like "I have now used 15 patterns in my project, do you think we should use more?"

Andrzej mentions in his blog post that Java (and C++) lacks dynamic capabilities so this is why sometimes, you need these design patterns to make your code more easily extendable. Other patterns are good even with dynamic languages (observers...).

Exactly. What many GoF critics seem not to understand is that Design Patterns is descriptive, not prescriptive. It's "what we've seen," not "what you should use."

I've heard people say that, but if that's true, why didn't they include many of the (much more commonly used, IME) patterns like Big Ball of Mud, Stovepipe System, Spaghetti Code, etc...? There's lots of nightmarish patterns/techniques that were omitted. I find no plausible way to account for that other than that the patterns are (perhaps implicitly) prescriptive.

Those are covered in the anti-pattern book.

Reinforcing my point. If those are "anti" patterns, they must be bad, right? Hence, patterns as described in GoF are good.

I think there's a line between "These are patterns that we have seen work" and "These are good patterns so use them". Back when I first read the book, I was pretty junior and I remember thinking "oh! I can use this...and this!". And built "wonderfully" over-architected code. Now I'll run into situations where after I starting working on some the solution I have resembles a pattern - and it's nice to be able to use common terms that the other developers will understand when you discuss it.

They're not 'Do this, and you'll have good code', they're just an observation that good code may often use many of these patterns - not because they're forced in there, but because the solution simply maps well to that kind of model.

The GoF book itself doesn't describe them as good, unequivocally.

It's been a while since I read it, but I remember using the book itself as ammo for arguing when not to use particular patterns. They cover trade-offs, and the situations when the pattern may be appropriate or not.

> Observer, the Adapter, or the Visitor

It depends on the programming language one uses, really. You won't find many references to these patterns on Python's mailing list (or at least I didn't when I was new to the language and used to spend a lot of time there, ~6-7 years ago). Also, when I've tried to learn Lisp or Erlang I didn't find any mentions to such particular patterns (or maybe only in passing), the focus was on something else. And I'm sure there are a lot of other languages outhere who don't bother with patterns.

Every language has design patterns. The patterns are different depending on the language, though. You don't use the observer pattern much when you've got proper delegates (or closures), for example. Design patterns are just the things you end up doing over and over in a language. MVC is a design pattern. Even something like Rails itself could be said to be a codifying and standardization of a set of design patterns.

You did not hear about observer, but you probably heard about publisher/subscriber (most gui frameworks use this, even wxPython with pubsub).

Adapter is a generic name. Compatibility modules that enable python code to run with python 2 and python 3 are adapters. For example: https://github.com/bartdag/py4j/blob/master/py4j-python/src/...

As for the visitor pattern: http://docs.python.org/library/compiler.html#module-compiler...

All languages have patterns. Case analysis is a common pattern in Lisp code I've seen. Another one is map-reduce. Tags are another one.

They're just not called design patterns. But note that the things in GOF weren't called design patterns in C++ until 1995 either (the GOF book largely predates real use of Java). They were called techniques, or just things you might see in multiple projects.

No sarcasm necessary.

I am pretty convinced that GoF did not expect how popular their book may become. Looking back, it is always easier to judge.

Looking back, with no offense to GoF, what happened can be understood. GoF did a great work for all these "I badly need to sell something new and hot to all these saturated development shops" guys. Read the pattern book once, teach it a hundred times for 2000$ a person. Great stuff.

Now, of course it is due to the single developer to use patterns or not. But the average developer is - well average. Using a pattern is much easier than to understand, when to use and when not to use.

I indeed should have been more precise in my statement: our code got bloated and unmaintainable because there are pattern all over. This is not GoFs fault, it is the fault of all the developers who just read the book and want to apply everything instantly, everywhere. It is also the fault of the community, who did not recognize at once, that pattern should be used only, if they solve a problem that is hard to solve without patterns.

I've worked in shops where GoF ruled. Everything was a factory, even the things that /weren't/ factories were being /called/ factories, and there were zillions of singletons peppering the landscape.

"You've got a singleton class with a single method and no members . . . why don't you make this thing a function?"

"Uh, it wouldn't be a pattern then, would it. Um, would it?"

And the XML. Oh, dear Lord. I have a doctor's slip now stating that I am allergic to XML and that's the reason I'm breaking out in hives, whooping for air and leaving the room.

I sometimes wonder what would have happened to the software industry if the entries in GoF had been written in a different order. Would we see a plague of Visitors and Observers?

Jive turkeys who apply patterns for the sake of applying patterns are the reason the code was bad. But don't blame the GoF.

I love the term "architecture astronauts", and you get them everywhere in this field, not just programmers.

I agree that it's not java the language (java's boring, but not unusable), it's the java culture from the last decade that drives people away.

No, there's a direct relationship between the architecture astronauts and Java-the-languages. Since Java is so simple and so lacking in abstraction mechanisms compared to almost anything else, you end up writing FactoryFactories and all the facades and all that code goop just to get any sort of halfway decent abstraction out of the language. Even things like the AOP libraries that directly muck with JVM bytecode are a direct consequence of the fact that Java-the-language is so brain-dead that it's actually easier for them to directly fiddle with bytecode than work at the Java-language level.

This lack of abstraction mechanisms was by design; it was supposed to be simpler than C++, and it is. Unfortunately, it came from an era where people still thought OO was the uberparadigm and it met every need in it simplest form. I think I can safely close the book on that as being false; at the very least you need OO with borrowed features from older-generation functional languages like closures and first-class functions, like Python or Ruby.

I do understand why there was a need for all these abstractions, but I just think it got way out of hand. "Programming" java became more about gluing frameworks together using XML than about writing code. The culture of enterprise java programmers directed people to bring in all these abstractions, "just in case" they might need them in the future. The language may be neutered, but the over-architects took the last bit of fun out of it.

I've really only been viewing this from the deployment side for quite a while, but when I'm trying to help you troubleshoot your relatively simple webapp, and I have thousands of lines of stacktraces that bubbled up through a half dozen frameworks, it's hard to blame just the language.

On the other hand, the last half decade shows a major improvement in the Java community.

Have you tried Java EE6 (the app-servers that support Java EE6 or just the subset of Java EE6 have improved significantly as well via OSGi).

>> a form of mental torture (Struts, anyone?)

If I had to name the single biggest class of make-work in my life in the last 10 years, that would be it: maintaining legacy Struts crap.

The creator of struts should be in Gitmo for a year or two, perhaps with access to a functional programming environment a few hours a week if he behaves himself :-)

Java: providing a job with benefits. Like the episode of "The Simpsons" where Homer has to go back to the nuclear power plant to work, to pay for his daughter -- "Do it for her."

As someone who was deeply involved with Java a decade ago, I feel your pain over the "hijacking." In truth, that crowd would have hijacked anything that came their way, it is a dynamic strongly influenced by the BigCo culture, it isn't really a tool thing.

The moment you set up "throw it over the wall" processes where architects are rewarded for architecture and implementors are blamed for bugs, you are going down the road to something that looks like J2EE no matter where you start.

That is precisely the root cause of it. Well spotted.

I agree with you about Play, it seems encouraging though I haven't used it for anything other than the tutorials on the site. Still not sure I'd want to use it over Rails or Python.

I'm worried that people will think I'm a broken record on the topic of java, but this discussion is coming up a lot these days, and I think a lot of people are doing a mental re-evaluation of Java. One thing that comes up a lot is that Java itself isn't terrible, but J2EE (as well as Spring and other frameworks many developers consider over-complicated) has made the experience of being a java developer (especially someone new to the environment) unpleasant.

While some people mention frameworks like Play, I'm interested in what people think of going back to the Servlet + Libraries approach that was common in 2004, just before Struts/Spring hit the scene. It's verbose, and I'm not saying we should just go back to the way things were, but I think developers might want to embrace the low levelness and verboseness of Java.

My take on it is - if I'm happy to work within the conventions of a framework, then I'd probably be happy with Rails or Django. If I want to write Java, then I probably want a very detailed level of control over my code base. In this case, it might make sense to start with the bare-bones (servlets and jdbc), and grow into what I think I need through libraries rather than an over-arching framework like Spring.

In general, I think I would want to use MVC and DI, but I'd like these things to be as unobtrusive as possible, and easy to add or remove, like libraries rather than something that dominates my code from the very beginning...

Honestly, my thoughts aren't completely formed on this yet... I just find it interesting how so many people on HN are starting to discuss this now. Often, there's a reason that developers start to focus on a particular issue at the same time.

First, let me point out that once again we are comparing Java - a runtime, a language platform and an entire ecosystem comprising many frameworks - with Rails, a specific web framework designed with a specific philosophy (opinionated defaults that work in 90% of cases, YAGNI, etc.) for a specific range of uses ("rapidly prototyping a small-to-moderately sized web site").

So just because Rails developers hate something doesn't mean it's generally evil. It might just be wrong for Rails. Many things are; otherwise Rails would have no texture. Saying no to things is what design is about.

Now let's talk about hate. Everyone hates something. There is nothing wrong with hating things. Hate is just personal taste turned up to eleven. You should strive to hate politely and with grace, to realize that other people love the things you hate and are nonetheless human, and probably even smart. And you should strive to remember that there's an important difference between the things you hate and things that objectively suck. Java, for example, does not suck. Not always. Lots of work has gone into it. Lots of Java-based tools are essential. There are big classes of problem for which Java is currently the best solution.

Nonetheless, I hate Java. It is a handy mental shortcut, one that has yet to lead me astray. My belief is that the problems for which Java-the-language is the solution are problems I don't want to work on, and that I don't have enough time in my life to address the problems I do want to work on, so I should simply develop a Java allergy that kicks in whenever I see the generics syntax and that causes my eyes to water until I flee towards fresh air. It works well.

(What's sad is when you find yourself hating something that is smack-dab in the middle of a set of problems that you want to work on. Hello, PHP! This requires a much richer set of coping techniques than simple allergic avoidance.)

(And, of course, Java is not just a language, and JRuby appears, from the outside, to be awesome, and my curiosity about Clojure is rising, so I may soon temper my simple hatred of Java into a rich melange of love and hate. The stuff of which novels are born, really.)

I agree with the you. While it's mean, I dislike the current state of the Java community for the reasons zeemonkee stated in http://news.ycombinator.com/item?id=2793472

The tough part about languages like Scala and Clojure is that the existing Java ecosystem bleeds through heavily. For instance, while Scala boils away a lot of repetitious code, it's still there under the hood. It feels like an architectural band-aid. That may change as the ecosystem around each language evolves and writes frameworks and libraries in Scala/Clojure rather than reusing them from Java. However in Scala's case it's as if the language is being marketed as the next evolution of Java-as-a-language with a heavy emphasis on reusing existing Java frameworks and libraries, so I expect the people writing code in the existing Java community to migrate to Scala.

Elitest? Maybe. But I think it's a realistic view.

The newer JVM languages are great if you already have an existing Java codebase, however I'm struggling to find sound reasons to use Scala on a geen field project.

Don't underestimate the JVM ecosystem, plus you have 15 years of optimization in the VM...

"For instance, while Scala boils away a lot of repetitious code, it's still there under the hood. It feels like an architectural band-aid"

I don't understand this argument. Even so-called elegant languages like Scheme still have 'repetitious' MOV, JNE, etc instructions under the hood. Unless you're running on a lisp machine, everything you write executes very repetitiously in machine language under the hood.

Why make a distinction between one abstraction and another? All of them are architectural band-aids, to use your parlance.

This idea of developing an "allergy" / "hate" for Java reminded me of http://www.npr.org/blogs/monkeysee/2011/04/21/135508305/the-... ( HN discussion at http://news.ycombinator.com/item?id=2464764 ). More specifically the part about "culling":

Culling is the choosing you do for yourself. It's the sorting of what's worth your time and what's not worth your time. It's saying, "I deem Keeping Up With The Kardashians a poor use of my time, and therefore, I choose not to watch it." It's saying, "I read the last Jonathan Franzen book and fell asleep six times, so I'm not going to read this one."

[...]

What I've observed in recent years is that many people, in cultural conversations, are far more interested in culling than in surrender. And they want to cull as aggressively as they can. After all, you can eliminate a lot of discernment you'd otherwise have to apply to your choices of books if you say, "All genre fiction is trash." [...]

The same goes for throwing out foreign films, documentaries, classical music, fantasy novels, soap operas, humor, or westerns. I see people culling by category, broadly and aggressively: television is not important, popular fiction is not important, blockbuster movies are not important.

--------------------------------------------

I also have this avoidance mechanism. I don't have enough time to learn about each programming language / framework / paradigm, so I kind of hate / ignore some of these, without really knowing them (PHP, .NET, Windows, "enterprisey Java solutions"...). Not sure if it's the right thing to do, but I still have plenty to learn with the languages / frameworks I am interested in...

What is sad is that I have culled so many things that I used to love, that I very likely still love. I used to be known among my friends as someone who watched a lot of movies. I don't watch movies anymore. Or TV. Or play computer games.

I'm not even certain why this has happened. As best I can figure, I am trying to create something and am still stuck in the phase where I figure out what the hell it is.

Interesting. I actually did the same. I haven't owned a TV since a few years. I often go to the theater, but I've stopped watching movies and series at home around 2-3 years ago. Same with computer games. This roughly coincides with a) getting my first job and b) discovering HN.

I seem to have replaced these hobbies with reading HN, reading books (lots of non-fiction), and toying with technical stuff (programming languages, libraries, security, ergonomy...).

While I learn a lot with these "productive" hobbies, I sometimes think I might be missing out on my previous hobbies... The NPR article made me realize I might have "culled" too much.

All you need to do to experience this first hand is go to one Ruby meetup. The roundtable introductions at my local Ruby brigade are often seasoned with AA-like declarations of soberness such as "Hi, I'm So-and-so and I've been Java-free since 2006." As a Java pro (and someone who really does like Java) it's a little disheartening. On one hand I know they don't really mean to belittle the technology that pays my bills and feeds my family, but there's a definite mindset of superiority among some professional Ruby-ist communities.

Java, by design, imposes an upper-bound on cleverness/productivity that can be feel stifling to some. Thus, it becomes a badge of honor to graduate to sharper tools, such as Ruby. Whether they're cutting themselves (and others around them) with them is another story, of course.

We need more devs who are not so emotionally invested in their tools. Not that they shouldn't care about them, but the loud-mouthed, posturing alpha dev stereotype gets too much airtime on the Internet because they instigate drama and drive hits by playing on the audience. It is little more than bikeshedding, ultimately.

I'm totally fine with different strokes for different folks. But I don't buy the productivity argument. For any reasonably sized project, productivity tends to level out regardless of language or platform.

Oh really..... try building a large scale web app in Forth then.

Tools matter, at every scale.

So your counter example is a relatively obscure language? I don't know Forth, but I'd imagine someone well-versed in it could handle the task. In any event I didn't say it was categorically the case. I said tends to be the case. We could go case / counter-case all day.

I can bootstrap a project in Ruby or Python considerably faster than I can in Java. But when it comes time to scale, Java usually -- not always, but most of the time -- wins out. They all can do it. None is really more expressive than any other. It's just the level of effort involved. And the pros and cons of each usually start to even out as a project grows.

I disagree. There is definitely a difference in expressiveness between languages for example Java and Lisp. Read "Revenge of the Nerds" by PG. But of course, you're right in the sense that I could implement a Lisp interpreter in any language...

If you honestly think there's no expressivity difference between Python and Java, you're still writing Java-in-Python. There are so many differences in expressivity I wouldn't even hardly know where to start describing them. The old 10-to-1 line advantage isn't a myth, line count matters (one of the only solid truths about software engineering we have proved with almost scientific rigor), and I've gotten more than 10-to-1 in some conversions I've done.

I'm not suggesting how you feel comfortable writing code. Like I said, if you just prefer it because it's less verbose, that's fine. There's absolutely nothing wrong with that. But that doesn't mean you can't accomplish the same thing with Java or that verbosity has a long tail impact on productivity. At some inflection point in just about every project, you stop mashing the keyboard and focus on the non-typing aspects of the codebase.

I think it's not really the size of the project per se but the proportion of domain complexity.

For problems with low domain complexity but involve a lot of boiler plate code, a more expressive language wins out. Likewise, if you spend the majority of your time thinking about the problem and little time on the actual implementation, then the language may not be your bottleneck.

I work in what is essentially a Java shop and the opposite is true for me. The Java programmers work on the data set and provide me with an API. My responsibility is to present the data using a Rails application in a sound UI and in the fastest way possible.

They often make remarks about how Rails is easy and Java programming is where real men make their mark.

I think this comes down to a need for people to feel proud about the tools they use and the things they make.

The opposite is true for me too.

I've had an Enterprise Java guy telling me once that "programming and Object Orientation got lost with those simpler, easy-to-use language and frameworks", referring to Ruby and Rails.

I dunno about that. Alan Kay would probably say that it got lost with C++ and Java, but YMMV.

Also, one word: speed.

But... I don't really think it boils down to this, it's not like one is better than the other. Proof is that both communities are learning from each other, and there's also JRuby... it's a great thing.

Why put "programming" and "object orientation" in the same sentence?

JRuby is actually for projects that have a lot of existing java code. If you're programming ruby and all your existing code is in ruby... it's not necessarily a win, unless you happen to need a particular Java library for performance reasons.

> I've had an Enterprise Java guy telling me once that "programming and Object Orientation got lost with those simpler, easy-to-use language and frameworks", referring to Ruby and Rails.

You did tell him Ruby is roughly as old as Java, Python is older and Smalltalk predates Java by almost 15 years right?

The comment doesn't seem to involve when the languages and frameworks were respectively created, though if you do look at the pairings (Ruby w/ Rails, Python w/ Django as large examples), they are relatively new after all.

There's a definite stigma attached to Java for where the tool is used most. I'd bet nine times out of ten, a randomly chosen programmer's previous Java experience was a Dilbert job. Proclaiming yourself "free of Java" should probably be worded "escaped from a corporate cube farm". I doubt they care that much about Java, especially with the buzz around JRuby and Mirah.

I recently went on an interview for a Python dev position. I've been a full time Java developer for the last 5 years, working on some cool shit. However I enjoy python more for my hobby projects, having many live python projects, shipped python code, and a github account with my python code.

After some good natured ribbing that he 'doesn't hate Java developers, he just feels bad for them' He finally told me quite directly that he was apprehensive to move forward with me because hes worked with Java devs who made the jump to Python and they wrote Python code that looked like Java and he wasn't certain I'd be any different.

It was quite bizarre as he had access to a lot of my Python code.

... Which he'd not bothered to read. Now ask, would you want to work for a manager who prefers preconceived notions to actually seeing what people produce?

Absolutely. We got a long great otherwise, but that one thing ended the interview on a sour note for me.

  "Refactoring came to us from Java"

Maybe the word came from the Java community but people have been carefully restructuring code since code was invented.

It didn't. The wiki tells us that it was first used in 1990, somewhat before Java was on the scene.

http://en.wikipedia.org/wiki/Code_refactoring#History

Smalltalk was famous for it.

Makes sense, I guess: Java was based on Objective C which was based on Smalltalk (and C).

Right, http://books.google.com/books?id=1MsETFPD3I0C&lpg=PP1... It actually came from Smalltalk, just for a change.

Well, Unit Tests also came from it (SUnit was the first Unit Test framework). Which is unsurprising, as refactoring without unit tests is quite daunting.

But JUnit did make them mainstream, and so did Eclipse' refactorings.

Interestingly, refactoring usually works quite well for functional Haskell code without tests just relying on the types. (Of course the types won't help you in more imperative sections of your code, i.e. it's hard to guarantee a specific order of actions in the IO Monad with types only.)

You mean just like in Java?

Yes. But the pure part of your program tends to be bigger in Haskell than in Java.

And the type system (and compiler) help you know what's pure and what's not.

Actually, the Smalltalk community got it from Forth, where it was called "factoring" (no "re-"). See e.g. Leo Brodie's _Thinking Forth_ (http://thinking-forth.sourceforge.net/).

> Maybe the word came from the Java community

Nothing of refactoring came from Java or its community. The formalization of its concepts largely came from the Smalltalk community (Opdyke, Johnson '90; Opdyke '92; Johnson, Opdyke '93; Opdyke, Johnson '93), using unit tests to ensure refactorings don't change behavior came from the Smalltalk community and automated refactoring tools came from the Smalltalk community (Roberts, Brant, Johnson '97; Refactoring Browser http://st-www.cs.illinois.edu/users/brant/Refactory/)

In fact, as you may note both the concept and the name are older than Java itself.

The only claim to fame Java has in relation to refactoring is Smalltalk refugees reimplementing IDEs and refactoring browsers for it.

We seem to have a rather short institutional memory. It wasn't that long ago (Java's only as old as Ruby) that Java was new and hailed as a savior from C++ and C. Java was widely seen as a great language, or at least a language that presented a great improvement over the existing mainstream languages. It gave GC to the masses for the first time. It delivered standard-sized primitives, an (almost) everything's-an-object design, a cross-platform runtime, JIT compilation, and a host of other improvements to mainstream programmers for the first time. Java has a lot of issues, but in the grand scheme of things, it's a pretty good language.

Stroustrup was dead on: "There are only two kinds of languages: the ones people complain about and the ones nobody uses." The more popular a language is, the more people will complain about it. (And the more people will build crappy software around it.)

> Java has a lot of issues, but in the grand scheme of things, it's a pretty good language.

Definitely not. Especially not in this day and age. Java has a pretty good language, java has a good ecosystem, java has a passable standard library, but in 2011 java is a crummy language.

Depends on what you want to do. Want to hack together a low-traffic website quickly? Java's a pretty poor choice. Want to build large-scale systems that are reliable and fast? Java might fit the bill pretty well. It's no coincidence that Google builds much of their infrastructure on Java. It's no coincidence that Hadoop is written in Java. And it's no coincidence that Twitter is rewriting much of their infrastructure in Java. Java is a good language for building Big Stuff.

dammit fingers. Java has a pretty good runtime.

It's been my experience that most people who put down Java or C++ or [your language here] have never seriously used the language and are insecure about learning a new language so they make fun of other languages to hide their insecurity.

Edit: I'll also add that this is not limited to the Ruby community.

One last edit: General Patton once said, "Find what a man is cynical about, and you will know his weaknesses." or something like that. I think that quote applies here.

I think developers like to think of themselves as above dogma, but threads like this show they are just as prone to fashion-oriented thinking as any other group of people.

Intellectual honesty is always in short supply on the Internet, it'd seem.

> General Patton once said, "Find what a man is cynical about, and you'll know his weaknesses" or something like that

Abraham Lincoln once said "If you are going to quote a man on the Internet make it accurate", or words to that effect.

Only messing, googled and it seems to be "Watch what people are cynical about, and one can often discover what they lack."

Sorry, I was paraphrasing and tried to make that clear. I think I captured the spirit of the quote.

Definitely, I was only joking.

Java and C++ were the first languages I learned, and I used them exclusively for about 5 years (mainly C++). I simply don't like either language. I think they have both have a lot of problems and downsides.

I'm not guaranteeing that this is true in an objective sense, but then again I can't guarantee that anything is true in an objective sense (I'm no philosopher). However, take a lot of people with a similar opinion and the voices tend to add up.

I used to think this when all I knew was C++ and Java, when I defended them feverishly. Then after using them for 5-10 years I am now in the "why do we torture ourselves with these inexpressive languages" group. These language should be criticized, or else your regular joe won't know any better and waste a large chunk of their life going down a painful path.

That's not to say they still don't have their niche for high performance applications. It's just that in most cases other, more expressive languages are usually a better choice.

Ok, I'll bite. I think insecurity is different than dislike.

If you asked me today what language would I use for a new web project, I don't think I'd pick a C based language. I don't really have much against that class - I use Objective-C every day. But I think it really comes down to the frameworks and libraries.

I spent the better part of the dot com coding in Java and C++. Towards the end of my Java days, the time it took to get ideas from paper to usable screen with JSPs, Spring, Hibernate - for one developer - seemed like forever. To make matters worse (and not so much Java's fault), I normalized the shit outta the database (a dba would have loved it) and having that fine grain of a data model just added insult to injury. So when I look at 'Java hate', I don't per say outright hate it, but I'm adverse to using it - especially for anything web. If you have a nice SOA, then I could see maybe using it for some services.

The last Java coding I did was in 2006 - that was my last Java contract client. After that, I switched to Ruby/Rails and that was that. A typical story I'm sure. Do I go to meetups and bash Java? No. Is the "eww, that would be like Java" heard around our office (current company is a Rails shop)? Yes.

However, my current company is hitting a ceiling with Rails. The fat model paradigm is starting to break down. Like us, as your project/app/company starts getting bigger and bigger, you start to hit growing pains with Rails. So I've been looking back at my Java history to find other patterns that were used to take some of the weight off the models and Modules where people have been putting things. Basically, Rails (IMO) is great to get you to a certain point, but after your system grows to a certain size, you have to start thinking about other ways to architect it. I think this is where SOA comes in and the data exchange is all done via json.

Would we consider using Java for any service? Probably not. Why? Because of the time and resources required to actually deploy the services. Like TFA says, Java picked XML. If someone actually made a simple app server where apps could be setup and deployed via properties (remember those?), then that might take some of the Java deployment sting out. Or, maybe if our team grabbed a dedicated release engineer, that might help.

So in the end, I don't think of myself or anyone I work with insecure about learning a new language. Most of the devs I work with came from a Java background. What makes more sense is being able to iterate very quickly over your ideas and just get shit done. This is why Ruby/Rails has been so successful. I don't find being cynical about Java a weakness at all. What would be worse in my mind is to get someone in who is not productive with the tools they're using. And for me writing web apps, I just don't feel productive using Java and its associated frameworks/libs/tools/servers.

If you ever do want to try out a new app server, what I do is use embedded Jetty. It's not an app server that you deploy your web app to, but rather your web app becomes a runnable application. This makes deployment to something like EC2 completely trivial. Just copy your app there and hit run.

Since you said "most people," I guess I'm disqualified from saying that I have deep Java experience and dislike the language, you can simply retort that I'm not a True Scotsman, I'm just an outlier. But nevertheless, I press on. I built Java development tools in C++, I led teams of 20+ devs, I built online banking applications, I wrote a Scheme interpreter in Java, yak, yak, yak, and yes I put Java down.

C++ is another matter entirely. My experience is pre-Boost, so I don't consider myself qualified to debate current approaches.

Java is awesome purely because of the large corpus of useful libraries. Apache, stanford NLP, etc. Universities and open source groups contribute a large amount of Java code and it really pushes the boundaries of the types of applications you can create that are mature and perform well.

Other than that I develop much faster in Python or Javascript. I've come to love treating functions as first class objects, and I just don't love static typing that much anymore.

Getting my projects done more quickly has become more important than anything else. It just so happens that other languages than Java are better for that.

I agree. I just want to get things done. It just so happens, fun languages like Python, and Ruby are better for that. I don't treat programming languages like religion, or sports teams. I treat them as tools to help me do what I need.

I felt the same about static typing when I first learned Python and Scheme. But I encourage you to give non-crappy static typing, like in, say, Haskell, a try just to broaden your horizon.

Java as a language is decent. It's boring. It is stagnant. I expect very little of it.

Java EE is an atrocity and it is just an over-enginnered pile of garbage.

Try play framework. I just finished a webapp in play and the whole experience has been awesome. IntelliJ + Play + MongoDB is AWESOME.

I haven't messed with the Scala version, but I can imagine that Scala + Play is even more interesting. Either way, Java EE/EJB/XMLHell is probably my most people hate Java. Also, Swing was garbage too, but who builds desktop apps in Java anymore anyway?

Play! Scala is really, really, really cool. The major downside--drink if you're expecting this one, folks--is the recompile time. Building an app is just so bleeping slow.

But writing it? Very nice, aside from the somewhat iffy SQL layer. (I'm not a huge ORM fan, and the process of actually writing SQL through Anorm can be problematic.)

For our app, we went straight up MongoDB driver. We didn't mess with an ORM at all. We still have our objects that end up mapping to Mongo, just not using a 3rd party lib. It's actually a really clean and enjoyable experience.

Huh, didn't think of that. I'll have to try it. Thanks a lot.

Have you tried jrebel to cut your compile time? It might ease some of that pain.

JRebel isn't applicable to Play - Play (both when running Java and Scala) hosts its own compiler. In dev mode, when you change a .java or .scala file, it recompiles it and reloads it on the fly.

Which is why Play is freaking awesome--well, one of the reasons.

Which version of Java EE you refer to? Last time I checked, Java EE6 is pretty sweet.

Keep in mind that the latest EE6 spec and most modern Java frameworks make XML optional (supported only for backward compatibility or just because it's there).

I believe there is hate because a lot of 'over engineering' was done in most projects. This then necessitated the need for more complicated (and `sometimes` useless) new Java techniques.

This most likely comes from seeing Java (or x,y,z) as thee only tool one would possibly need. Unfortunately, Java much like every other lang should be seen as a tool with pros and cons, in a chest of other tools.

Also, it's bad measure to only consider deployment size regarding any platform effectiveness.

" Let's learn more from Java". I'd rather learn more from "Computer Science" and apply those techniques to Java. Not the other way around.

Over the course of the past few years, a lot of the overengineering mindset has been leaving the Java community. Bruce Tate and others have had a significant impact on this shift. More dynamic languages becoming available for the jvm has also helped, as well as lightweight frameworks like guice and picocontainer that permit some degree of complex configuration injection without the overhead of past solutions.

Java's ecosystem is changing, albeit slowly.

> I believe there is hate because a lot of 'over engineering' was done in most projects.

Just reading this and thinking: "oh man, if ONLY that was my problem".

I've done a ton of Java work, server side and desktop apps. What really amuses me about Java advocates is how they don't realize that the XML is not there for "configuration", it's there to form a dynamic (non-statically typed) appendage to the language. The trick of Spring and similar tools is that under the covers they use the reflection API. It's sort of a joke to claim that you are using static typing, when the config files are more or less a contained bit of dynamic typing.

Yeah... A lot of Java apps are really just runtimes for the actual app, which is written in a one-off language wrapped in XML tags.

Java != XML

I code in Java all day every day and I haven't touched a line of XML in years.

Two other reasons I avoid Java the dependencies ecosystem for a typical Java app is bloated and always changing, and it didn't really live up to the promise of write-once-run-anywhere. And by the way, the over-abstraction habit is really annoying when you're trying to write a simple util app and you can't just say foo = new Foo() instead you have to extra nonsense such as factory = new FooParamsFactory() then fooparams = factory.getFooParams() then then foo = new Foo(fooparams) ... it's nice to get away from that nonsense. I just find Java to the playpen of architecture astronauts who would rather design APIs than write apps.

"it didn't really live up to the promise of write-once-run-anywhere"

Care to explain this one? All the code I have written for the past 10 years do not need to be recompiled and can run on Windows/Linux/Mac/*BSD 32 bit/64 bit. And I used IO, NIO, sockets, threads, files (not necessarily high-level stuff).

It turns out that there is a level of abstraction where every desktop OS is just like every other. And Java evolved to exploit this common ground.

But the ultimate lesson was that the intersection of all operating systems is an awful place to live. Because Java's not-exactly-native widgets often have the wrong look, it feels generic. Because they often have subtly different semantics, it feels slightly alien. Because platform-specific behaviors like drag and drop generally don't work right, it feels like an outsider, even though it's running on your machine. And because the app requires a giant brick of a runtime that generally hasn't been preloaded by anything else, it starts so slowly that you can practically hear the gnomes turning the rusty crank on the starter motor.

And it's not as if these are fatal objections. Clearly, based on the success of the web, they are not. But the lesson has been: If you're going to run an idiosyncratically-designed slow-loading quirky app that's imprisoned in it's own window why not just run a web app. And that's what people do.

For non-gui work it mostly lives up to that promise, but if you're building a consumer app you end up having to do a lot of tweaking per-platform.

I have maintained Java apps running on FreeBSD servers, it was a nightmare. And don't even dream of doing that in OpenBSD (which IMHO is the sanest BSD and even nix around).

What kinds of problems did you run into?

I've deployed onto primarily Solaris and various flavors of Linux with no problems, but don't have much experience with *BSD... though I've generally assumed it would be a similar experience.

Problems like having to patch and build your own Java runtime because (if you are lucky and there is a working one) because Sun made it illegal to distribute modified Java distributions that had not passed the test-kit, and everyone should know that Sun/Oracle do not give access to the test-kit to anyone that doesn't pay them a ton of $$$.

I've done my share of Java GUI programming (and still have Java applets running on a fairly active site... I can't replace them -- HTML5 and Flash aren't likely to support MIDI input, ever), and the "write once run anywhere" flaws are generally all in GUI programming.

But I think everyone has known for a long time now; that's not Java's sweet spot. It's do-able, but for obvious reasons it's harder to do cross-platform, and they made a few large missteps along the way trying to crack that particular nut.

Nowadays the vast majority of my Java work is server-side, and it all runs anywhere, without a hitch. The last time I had cross-platform Java issues with server-side code was on an AS/400.

I may be the target of this article. I like Ruby quite a bit and I don't like Java at all. The word "hate" isn't quite appropriate, but here's my problem with Java:

I hate how much work Java makes me do to get things done.

It doesn't matter if you're writing "hello world", an English to pig-latin converter, a web server or a lisp interpreter. In every case, it's a lot less code and a lot less work to do in Ruby than it is in Java. Java is just too low-level of a language for anything I'm working on, and in those cases where I do need to get closer to the metal, it's easy enough just to use C.

Long live the JVM and here we go again comparing Java to Rails the framework. I've seen the pros and cons of both Java and Ruby. From an organizational standpoint it's hard to beat Java. The performance is there and in a team setting statically typed languages really shine. You can argue about the quality of programmers that flock to Java quoting pg ad nauseaum but we don't live in a lisp world. Elegant code is written by good programmers not the language.

Ruby is fun and really nice for exploring ideas though. It doesn't marry you to an IDE and you can go from idea to reality quite fast with a text editor and a command line. Unfortunately, Rails is a lot of meta-programming magic and syntactic sugar that can really obscure the language for newbies. It's changed the landscape for web frameworks and I would even say mobile as well. RoR didn't invent MVC but it certainly refined our thinking of frameworks in general.

> Elegant code is written by good programmers—not the language.

But some languages make writing elegant code easier than others (compare C to Python, for example).

For some task-specific definition of elegance. For me, elegance is not just about how terse the syntax is, but how well it solves the problem at hand and responds to changes around it. For me, some problems require a performant solution as well, and the elegant option is the one that does this without requiring a bunch of rewriting or adding hard to discover dependencies.

I can write some terse AND elegant list comprehension code in Python that takes lines and lines of crappy looping in Java, but I can also write some seriously terse code to centralize business logic via a web service with automatic transaction and security management and have it perform an order of magnitude faster than a similar implementation in Ruby or Python (JEE 6). To me, that is elegant.

Likewise, I can do some elegantly maintainable things with .NET generics that I can't do with Java's lame erasure based implementation.

Of course, you could always just takes Einstein's opinion :) "If you are out to describe the truth, leave elegance to the tailor."

I don't hate Java. I just prefer to write code in Ruby.

Another reason to stop hating on Java is that in a lot of cities, it would be a fool's errand to assemble another kind of dev team. Like Ruby? Great. Good luck building a team in Omaha.

Skills go where the jobs are: http://www.indeed.com/jobs?q=ruby&l=Omaha%2C+NE = 11 jobs http://www.indeed.com/jobs?q=j2ee&l=Omaha%2C+NE = 101 jobs

Bottom line: if you expect to hire developers, in most places, you'll want a language with the deepest bench of talent. The trick is to resist the Java framework nazi's and keep it simple.

Unless you have horrable retention issues highering someone who does not know the language your using is not that big of an issue. Taking a C# ASP.NET developer > Ruby on rails is faster than bringing a Java developer who knows nothing about the web into a large Spring/Struts project.

That might be true for a basic/early Rails app where it's ok to have script kiddie relationship with Ruby, but if you have a more complex app, I don't think the learning curve is quite as easy as you're making it sound.

My own experience with Rail is that I quickly wanted to see inside and control all of the implicit stuff that was going on, and I needed to invest a lot more time to learn Ruby to have the knowledge that would give the amount of control I wanted.

Hiring any programmer that can't adapt to an unfamiliar new language is a bad idea (TM).

I'm far from a guru, but I've been able to pick up quite a few different languages, frameworks and structures over my tenure. It's the ones that limit themselves to a single language (be it Java or not) for long periods of time that you need to worry about.

These are the programmers that will build a square wheel because that's what the spec told them to build. Employ them at your peril.

That's cool, but when I'm hiring a team and paying their salaries with my own money, I'm just not going to bank on transitioning anyone from X to Y. No time for it, no appetite for the risk. But if you raise VC, more power to you.

No. I prefer to continue hating Java.

Having recently decided to abandon my anti-Java prejudice from way back I've discovered that everything I hated about Java back in the 90s is still there, only worse.

COBOL at least had the excuse that it was first.

Job search in New York City on Dice.com: Java - 2698 Ruby - 204

Even within the Ruby jobs, the majority have a Java requirement within them as well.

Been hearing Ruby aficionados for like a decade, but sorry, it just hasn't penetrated.

I think this metric is invalid, the market rarely takes what's best, but rather what's trendy.

Before you begin to troll me, what I'm saying is that >>the metric is not valid<<, not that one language is better than the other.

While being strong in the market doesn't necessarily quantify better/worse or more/less elegant. But it does mean the tires have been kicked a lot more.

One thing I've learned is that your language/framework is an HR decision.

The jobs metric tells me that if you hope to hire >>experienced<< Ruby programmers, you can probably expect to have fewer to choose from, possibly wait longer, fight harder, and pay more to get them.

I'm not saying you can't hire good programmers and give them a few months to transition, but that wouldn't work for my bootstrapped startup that's planning to ship product in 90 days.

You might say, yeah, but with 2k Java jobs, you have to compete against a lot of employers. Personally, I'd rather take my chances with a deeper pool of Java talent that I can out recruit the competition.

This hardly starts to address the things people dislike about Java. Sure, it's a capable language - the JVM even more so. The thing is, it hasn't kept up with the pace of everything else. The JCP is clearly broken.

The best thing for people would be to move on, not in anger but to explore as many languages as possible. Java could very well be the best thing for some BUT you can't really say until you go out and look. From where I'm standing (subjective since I left Java ages ago) most people that go out to explore new things rarely go back.

That's an important point.

When Java came out it was a big step forward for a lot of people. Most of the scripting languages with OO features (Ruby, Python, PHP) have a lot of Java influence.

I see the problem is that Java stopped evolving a decade ago. C# shows the kind of path that a Java-like language can follow to get better, and Java just hasn't been moving.

Scratch Ruby and Python from your list and I'll agree with you on the OO influence! Not to mention Python is older than Java. I think most of the 'scripting languages' with OO have decidedly not gone the Java/C++ way.

Other than that I'm pretty much in agreement. Even not so long ago as 2002 people would say "Let's use Java" when they really were saying "Let's NOT use C++." C# is a great language, though MS didn't put their heart into really killing Java. I think Microsoft could have dominated with C# outside of Windows World (lots of enterprises still rely on Linux, and Java's not a bad choice for an enterprise app on a Linux server, then there's Android..) if they put more backing behind Mono or just open sourced everything to begin with.

I don't hate Java, I just don't want to use it.

I find it ridiculously verbose, and the lack of closures (or even passing around code references) leads to the perceived overengineering mentioned in the post (I'm not sure it's really overengineering all the time - it's just that a rather rigid language forces you to write huge amounts of code to make your library flexible).

That said I have no problem with using programs written in Java - in that case somebody else has already dealt with the things I don't like about Java.

It's not overengineering, it's greenspuning[1] around the expressiveness limitations of the langage to make the code flexible.

[1] - http://en.wikipedia.org/wiki/Greenspuns_Tenth_Rule

What's the general consensus in the HN community regarding GWT? We're pretty happy with it and I think it has a lot of advantages over other frameworks.

I can't speak for others, but I hated it. The people I know who liked it were the ones who were scared of JS because they didn't know it very well. The problem with GWT is that if you want to do anything semi-complicated you end up needing to write native JS anyway. So you end up with an ugly cludge of an app written in two different languages and cobbled together with a JNI-like mechanism. I also had a ton of trouble getting their funky debugger to work correctly. Writing in Closure is soooo much nicer. The Closure compiler can give you type safety, which seems to be about the only benefit of GWT.

Regarding the debugging features, I think things have gotten a lot better. Debugging is done in Eclipse and you're debugging java, not javascript (if that wasn't clear to some). It honestly works really well. I think there are also quite a few benefits other than type-safety. Easy implementation of asynchronous calls that serialize Java objects is one example.

GWT does have its drawbacks, but we do a lot of complex work in it with very minimal native javascript and support a site with hundreds of thousands of active users.

I still can't believe GWT is not an April Fools joke, and I'm stunned that anyone ever took it seriously.

Please elaborate. So many people on HN love their newest language of choice and overlook frameworks like this because it isn't as sexy. As I mentioned in my previous comment, we have a pretty large site by most standards and are happy with GWT.

“If you drop static methods, then welcome to Java and its billions of useless factories.”

And if you use them everywhere, then welcome to Rails, where to service more than 1 request at a time you actually have to run multiple instances of the whole app behind a balancer.

Ruby and Java serve different developer segments, it's much more fun to compare Java and C#. Java and C# are languages that are pretty much the same, serve similar markets but one of which I vastly prefer to program in because of the little niceties: no checked exceptions, first class functions, closures, properties, etc.

Comparing Java to Ruby is a philosophical matter, comparing Java to C# illustrates numerous ways in which the language and runtime (real support for generics) could improve while staying true to its market.

The article honestly looks like a comparison between rails and java rather than ruby and java.

I have a question...

The article states:

... Whenever you needed a pluggable system in your code you had to abstract away some concepts in order to make it work. Ruby lets us do it much easier and that’s cool. ...

Can someone give a concrete example of this?

Java had many problems with absurd over-engineering (aka EJB2) in the past. Even today, a LOT of legacy code is over-engineered and a pain to mantain.

That said, it is possible to write thin apps with Java today, much by the innovations brought by SpringSource. Roo is a rails-like framework to Java that works really well, and the Spring container took out the word EJB from almost every new project.

If I have to choose a language to start a new project today I will probably go with other language, but I have no problems working with Java at all.

I have to profess I haven't coded in Java for about 5 years. But when I did, Spring and Hibernate are what drove the final nail in the coffin for me. I'm sure it's changed but after that experience, I never felt the need to revisit.

Kinda like that one girlfriend that messed you up so bad that once you got over everything and realized life was ok, you never felt like rolling by her house ever again. :)

I am not in the mood to defend Java, but I would like to give a tip to people who keep mentioning J2EE: J2EE is from a bygone era; learn to say Java EE 6, which is better (although JPA 2 is really the only part I like) and take J2EE out of your vocabularies. Discussing J2EE kind-of makes it sound like your knowledge is out of date.

Also, Scala and Clojure are wonderful languages so I don't understand some of the negative comments about them.

C# is a better Java anyway.

As far as the language goes, I agree with this but I'd take JVM over CLR anytime.

"but I'd take JVM over CLR anytime"

Because of cross-platformity, or is there more?

Because it's cross platform, yes. Huge advantage.

Also, performance. Both the .NET and Mono JITs are still significantly behind HotSpot.

Modula-3 was a better Java way before somebody thought of naming a programming language after an Indonesian island…

[considering that there are 17000 Indonesian islands, this statement might not be factual]

The part that I don't like is when I can't write a webapp in Java because I don't know about Hibernate and JBoss and Maven and servlets and JDBC and more. I'd love to try a strict language, having used only Clojure and Python lately. Playframework might be an alternative.

It doesn't have to be strict. Try a lazy language for a change.

> I'd love to try a strict language, having used only Clojure and Python lately. Playframework might be an alternative.

Try Go.

Didn't all those "good" things he mentions that come from Java actually come from other languages (Smalltalk, Haskell, Lisp, ...)?

I believe the fact that Oracle owns Java is almost reason enough to hate the language.

dammit its a tool, whats the big fuss about. People can act so juvenile some times.

I'm with you. We all have our preferences. Use whatever tools makes you feel more productive. Ideally all of your code should be language agnostic. An algorithm is an algorithm in any language. While developing programs I've found that coding itself takes the least amount of time, is figuring out the algorithms, overall architecture, and debugging that takes most of the time. The coding part is the easy part.

I do agree that Java has some junk in it, but you don't have to use it. I'm sure I could say the same thing about any language though. I still prefer Java though.

It is not easy to avoid the nasty pieces of "factory factory" patterns if the people who you have to work with think it is a great idea. The problem is not peculiar to Java. I spend most of my C# time stepping through OPF (other people's factories) before hitting the code that actually performs some work.

> "I always disliked the XML impact on the Java frameworks. It didn’t come from nowhere, though, let’s be fair. Java as a languages is not as readable as Ruby, so it wasn’t perfect for configuration. Yaml wasn’t popular and JSON was still not really mature back in 2000. Something had to be chosen and that was XML. What would you do better back then?"

This piece seems to be mistaking criticism of technology with criticism of people, which is what happens when nerds get too personally attached to languages, frameworks, OSs, etc. I don't think Java folks are stupid for using XML, or anything of the sort. The above succinctly lays out the reasons why that choice made sense at the time, but times change, and that is not a reflection on the judgment of those who made this decision.

What I don't understand is, why does this guy care if other people don't like the language he likes? It doesn't change the number of Java jobs or the kind of things you can do with the JVM, so why does he care if a bunch of Rubyists hate Java? Also if he doesn't want people to hate his language, maybe he should use something other than Java.

On the sidebar of the article

"Available for Rails contracts/consulting"

You might a well ask, why fight against ignorance?

It does change the number of Java jobs.

The more advocacy happens for a technology - often - the more adoption it gets. While not entirely a zero-sum game, a tech choice for a company generally precludes them from seriously using alternatives. If a company switches from Java to Ruby, for example, that's fewer Java jobs, and more Ruby jobs. I'm working with an org doing this right now, and they will then be looking for Ruby devs instead of Java devs. Seems pretty straightforward to me.

Why would the OP using languages other than Java stop people hating Java?

Reply on news.ycombinator.com