Hacker Timesnew | past | comments | ask | show | jobs | submitlogin

I don't specifically hate Java the language, although I'm not enamoured with it either. I do hate the whole culture / attitude and baggage that comes with the language if you have to use it in an enterprise environment. That same culture that warped XML from something moderately useful into a horrible joke. Same goes for SOAP, UML and basically all things 'enterprise'.

edit: I gave up on the whole thing when I had to use comments to configure part of a build process. (xdoclet & jboss? ... I can't quite remember)



Yes, we were talking about this specific thing at work the other day. How come all non-trivial Java programs end up a mass of Factory and Implementation classes?! Several of the systems I support even weave in Spring, which while helping in some ways, completely obliterates readability. :(


My theory is that the language's lack of complexity bothers 'high-end' Java devs at a subconscious level, so they think they have to invent it in order to seem relevant to the larger community. Another idea is they may believe elegance is a function of using powerful language constructs, rather than a function of minimalism.

I see the same problems in Ruby sometimes: metaprogramming used without a compelling need. Luckily it isn't as much of a PITA because nobody thinks its OK to program via XML files anymore.


Java is way more complex than it should be, specially after badly botched features like generics were added.


I believe it is because the complexity more or less has to exist, when you remove it from one place(in java's case the base language) you add it in another(in java's case pattern soup). Just think about how you would solve the problems patterns solve for Java in other languages. In every case that doesn't require pattern soup involves language features Java left out.


You're right in that there's a certain base level of complexity due to the problem being solved.

But I think it goes beyond pattern soup, and beyond what's available in the language. It's almost a neurosis specific to the Java ecosystem that every design must be maximally flexible...perhaps to show off how object-oriented the code is? It's like the devs are reluctant to hardcode anything, instead abstracting over every design decision they made. This wishy-washy design is then played up as 'flexibility,' rather than a design failure.

Suppose I'm looking for a JSON serialization library. Do I really need to be able to configure the JSON parser used? What percentage of people need to do that? The people with the thorny problems (such as deserializing 100MB of JSON as fast as possible) probably won't be able to use it due to the scope of their problem. But, the option is there, as it could happen.

I haven't done Java stuff within the past few years, but it would appear they're getting better about it. It seems like it may have taken something like Rails in order to show the world that 'enterprise' is usually a euphemism for 'lacking in taste.'


>"But, the option is there, as it could happen."

And you know someone is going to use [awful library] to solve [big problem] and it will "work".


It's a compensation for not having closures. Many Patterns are.


Enterprise often over-engineers things.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: