Why people hate Java?
In my opinion Java is good language. I cannot understand people here and on reddit blaming Java often without reason.
8 comments
Your opinion based on what? How many years experience do you have, how many different languages do you know, how many different kinds of languages (imperative, declarative, functional), how many have you used to build real working production applications? The latter is all that counts as "experience" really.
Java is disliked because it is the lowest common denominator and employers tend to over-estimate the value of doing everything in the same language and under-estimate the value of using an appropriate language for the problem domain. So there are an awful lot of people whose professional experience is telling them that another tool is right for the job, but they've got to hit that screw with a hammer anyway.
Java is disliked because it is the lowest common denominator and employers tend to over-estimate the value of doing everything in the same language and under-estimate the value of using an appropriate language for the problem domain. So there are an awful lot of people whose professional experience is telling them that another tool is right for the job, but they've got to hit that screw with a hammer anyway.
I have plenty of experience. But I'm work in academia so my experience differ.
As I thought Java disliked not because design. It's human factor. Use ruby for number crashing and you will hate it.
Thanks for comment.
p.s. My primary tools are python and matlab. And I have to say sometimes static typing is must.
As I thought Java disliked not because design. It's human factor. Use ruby for number crashing and you will hate it.
Thanks for comment.
p.s. My primary tools are python and matlab. And I have to say sometimes static typing is must.
But I'm work in academia so my experience differ.
That explains a lot. Let me take a wild guess: Have you built a real project using J2EE? (Don't feel bad if you haven't: I haven't, either.)
The fundamental problem with Java is one of culture. After the idea of the Java applet died the true death and Java on the desktop retreated into its small niche, the Java universe became dominated by architects of spectacularly complex, overengineered middleware. When you hear a Ruby or PHP or Python programmer cursing "Java", that's often what they're cursing: The school of software architecture that implicitly equates enterprise quality with having a large number of complicated moving parts.
The higher-order problem is that the Java language and tools have evolved to fit the needs of this culture, such that you can't really use the language anymore without an IDE -- a piece of code that is, itself, more complex than the space shuttle -- to generate and track the boilerplate for you and help you navigate your own code. And the type system is out of control. It has become so baroque that it makes constitutional law and the Generally Accepted Accounting Principles seem trivial. I've taught myself Java three different times -- at the 1.0, 1.2, and 1.4 versions -- but I understand that Java 5 has introduced generics. I went to see what was up with that, and I found this blog post:
http://weblogs.java.net/blog/arnold/archive/2005/06/generics...
Then I found Bruce Eckel, whose books helped me to learn Java the previous three times:
http://www.artima.com/weblogs/viewpost.jsp?thread=214112
Java continues to ossify, pursuing its endless quest to produce the perfect program through static type checking, by adding more and more. The good thing is that people are finally beginning to see that static type checking is useful in small amounts and intrusive in large amounts (although I suspect this realization won't reach the main group of Java designers for years to come).
The bad thing is that, in the meantime, we get abominations like Java "generics"; via daily use people are finally beginning to see what I tried to explain years ago -- Java "generics" are far more painful than helpful, just like checked exceptions.
Yikes. Then I found the Generics "FAQ":
http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.ht...
which is 513 pages long, if you include the index. The FAQ needs a fucking index.
So: I've decided to remain deliberately ignorant of Java 5, and I'm happy. Perhaps someday you will want to forget about Java, too. If not, congratulations -- you'll be happily employed, fixing other people's Java code, forever.
That explains a lot. Let me take a wild guess: Have you built a real project using J2EE? (Don't feel bad if you haven't: I haven't, either.)
The fundamental problem with Java is one of culture. After the idea of the Java applet died the true death and Java on the desktop retreated into its small niche, the Java universe became dominated by architects of spectacularly complex, overengineered middleware. When you hear a Ruby or PHP or Python programmer cursing "Java", that's often what they're cursing: The school of software architecture that implicitly equates enterprise quality with having a large number of complicated moving parts.
The higher-order problem is that the Java language and tools have evolved to fit the needs of this culture, such that you can't really use the language anymore without an IDE -- a piece of code that is, itself, more complex than the space shuttle -- to generate and track the boilerplate for you and help you navigate your own code. And the type system is out of control. It has become so baroque that it makes constitutional law and the Generally Accepted Accounting Principles seem trivial. I've taught myself Java three different times -- at the 1.0, 1.2, and 1.4 versions -- but I understand that Java 5 has introduced generics. I went to see what was up with that, and I found this blog post:
http://weblogs.java.net/blog/arnold/archive/2005/06/generics...
Then I found Bruce Eckel, whose books helped me to learn Java the previous three times:
http://www.artima.com/weblogs/viewpost.jsp?thread=214112
Java continues to ossify, pursuing its endless quest to produce the perfect program through static type checking, by adding more and more. The good thing is that people are finally beginning to see that static type checking is useful in small amounts and intrusive in large amounts (although I suspect this realization won't reach the main group of Java designers for years to come).
The bad thing is that, in the meantime, we get abominations like Java "generics"; via daily use people are finally beginning to see what I tried to explain years ago -- Java "generics" are far more painful than helpful, just like checked exceptions.
Yikes. Then I found the Generics "FAQ":
http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.ht...
which is 513 pages long, if you include the index. The FAQ needs a fucking index.
So: I've decided to remain deliberately ignorant of Java 5, and I'm happy. Perhaps someday you will want to forget about Java, too. If not, congratulations -- you'll be happily employed, fixing other people's Java code, forever.
When you hear a Ruby or PHP or Python programmer cursing "Java", that's often what they're cursing: The school of software architecture that implicitly equates enterprise quality with having a large number of complicated moving parts.
The higher-order problem is that the Java language and tools have evolved to fit the needs of this culture, such that you can't really use the language anymore without an IDE -- a piece of code that is, itself, more complex than the space shuttle
Contrast this with the Smalltalk environment. It's also not very comfortable to do Smalltalk without the IDE, but someone who actually looks at the code of the "IDE" soon discovers that there's relatively little mechanism there. (I know of one "workspace" in a commercial Smalltalk that was implemented by a bored developer in the intro class.) All of the metaprogramming entities are ordinary first-class Objects, so almost the whole "IDE" is a relatively straightforward ordinary app.
Commercial Smalltalk environments also tend to fall prey to the Enterprise = Complex mentality, though.
Someone needs to create a programming language where "There's a Simpler Way to Do It!" is the mantra.
The higher-order problem is that the Java language and tools have evolved to fit the needs of this culture, such that you can't really use the language anymore without an IDE -- a piece of code that is, itself, more complex than the space shuttle
Contrast this with the Smalltalk environment. It's also not very comfortable to do Smalltalk without the IDE, but someone who actually looks at the code of the "IDE" soon discovers that there's relatively little mechanism there. (I know of one "workspace" in a commercial Smalltalk that was implemented by a bored developer in the intro class.) All of the metaprogramming entities are ordinary first-class Objects, so almost the whole "IDE" is a relatively straightforward ordinary app.
Commercial Smalltalk environments also tend to fall prey to the Enterprise = Complex mentality, though.
Someone needs to create a programming language where "There's a Simpler Way to Do It!" is the mantra.
Good point about Smalltalk. Not all IDEs are created equal, nor are IDEs in themselves necessarily a bad thing.
To be fair, all good languages can be used to create something that's more complex than humans can understand. That's what they're for. Languages in which complex things are impossible to create are incredibly frustrating.
Good software systems have three features: Most of the complexity is invisible at any given time (Ruby on Mac OS X is horrendously complex, but the author of Hello, World in Ruby needn't know that); the visibly complex things are built out of conceptually simple parts (e.g. Smalltalk Objects), and the visible complexity is needful: You build complex things to solve complex problems, but you don't bolt a lot of complicated stuff onto the side of Hello, World just because there are automated tools to help you do so. I think Java fails test two, and I'm certain it fails tests one and three: My impression of a page like this:
http://java.sun.com/j2se/1.5.0/docs/api/java/util/LinkedList...
... is that now a beginner can't even instantiate a simple list of objects in Java 5 without understanding generics and their syntax. Or, rather, I'm sure he can, but he does it by typing in some code, watching his IDE complain at him, and accepting the fix that the IDE suggests without bothering to understand it. And so begins his Java career, a career which will largely consist of standing by as his IDE conducts an automated, visible running dialogue with his language's increasingly complex spec. And for what benefit?
To be fair, all good languages can be used to create something that's more complex than humans can understand. That's what they're for. Languages in which complex things are impossible to create are incredibly frustrating.
Good software systems have three features: Most of the complexity is invisible at any given time (Ruby on Mac OS X is horrendously complex, but the author of Hello, World in Ruby needn't know that); the visibly complex things are built out of conceptually simple parts (e.g. Smalltalk Objects), and the visible complexity is needful: You build complex things to solve complex problems, but you don't bolt a lot of complicated stuff onto the side of Hello, World just because there are automated tools to help you do so. I think Java fails test two, and I'm certain it fails tests one and three: My impression of a page like this:
http://java.sun.com/j2se/1.5.0/docs/api/java/util/LinkedList...
... is that now a beginner can't even instantiate a simple list of objects in Java 5 without understanding generics and their syntax. Or, rather, I'm sure he can, but he does it by typing in some code, watching his IDE complain at him, and accepting the fix that the IDE suggests without bothering to understand it. And so begins his Java career, a career which will largely consist of standing by as his IDE conducts an automated, visible running dialogue with his language's increasingly complex spec. And for what benefit?
The folks around these parts tend to be from the dynamic languages camp. Folks who work in Lisp, Perl, Python, Ruby, and Smalltalk, tend to look at Java and see nothing more than unnecessarily chatty, and annoyingly prim, code. Most people here accept that Java has a place, but they'd usually prefer that place to be far away from their own projects.
You might like to read the pg article that summarizes much of (and may even be partially responsible for some of) the Java-hate you'll see around here:
http://www.paulgraham.com/avg.html
You might like to read the pg article that summarizes much of (and may even be partially responsible for some of) the Java-hate you'll see around here:
http://www.paulgraham.com/avg.html
Java has engineered itself to be many things to many people, and so applications built in Java can't really contain streamlined code because you still have to do a few simple things up-front.
Take a J2EE app, for instance; the servlet interface allows you to do a lot that can trip you up. Not having multithreading in servlets unless you specifically design for it is one of those things. Leaving SingleThreadedModel in the code, which is a really bad way to ask for multithreading in servlets, is something that a lot of haters can point to and say 'Java is Stupid'.
You can certainly get around servlets by working in a J2EE framework such as Struts or Spring, but that attracts more haters who point to all the jars you have in your library and say that 'Java is Overengineered'. If you don't believe me, check this brilliant 'Mac vs PC' spoof: http://railsenvy.com/2007/5/14/ruby-on-rails-commercial
So, while some languages are trodding a careful path between Stupid and Overengineered, Java is riding the pendulum, crashing wildly into both sides with wild abandon. And that pisses all the programmers off in a mighty big way.
Take a J2EE app, for instance; the servlet interface allows you to do a lot that can trip you up. Not having multithreading in servlets unless you specifically design for it is one of those things. Leaving SingleThreadedModel in the code, which is a really bad way to ask for multithreading in servlets, is something that a lot of haters can point to and say 'Java is Stupid'.
You can certainly get around servlets by working in a J2EE framework such as Struts or Spring, but that attracts more haters who point to all the jars you have in your library and say that 'Java is Overengineered'. If you don't believe me, check this brilliant 'Mac vs PC' spoof: http://railsenvy.com/2007/5/14/ruby-on-rails-commercial
So, while some languages are trodding a careful path between Stupid and Overengineered, Java is riding the pendulum, crashing wildly into both sides with wild abandon. And that pisses all the programmers off in a mighty big way.
Verbosity.
Also I tend to come across code like this a lot in Java:
Person p = new Person(new CarbonBasedLifeForm(new HomoSapien()));
Also I tend to come across code like this a lot in Java:
Person p = new Person(new CarbonBasedLifeForm(new HomoSapien()));
In my experience, the problem with Java is typically the code that is written. Average coders generating enormous numbers of classes/interfaces and not really understanding the problem/machine/etc. Java that I have written by myself or in small groups of seasoned engineers had a decent outcome.
My experience with Java is that the bosses of MegaCorp Inc. see banks & insurances using it, so it must be good.
The result is cost on the project being multiplied by, oh, a factor of 10, and the release date pushed back to sometime next leap year.
The result is cost on the project being multiplied by, oh, a factor of 10, and the release date pushed back to sometime next leap year.
just look at this discussion:
http://news.ycombinator.com/item?id=283639
Python lacks some features from Ruby, which does in turn not have some features which Python has.
Java lacks both. Its featureset is designed for OOP and does not faciliate different programming styles.
Python lacks some features from Ruby, which does in turn not have some features which Python has.
Java lacks both. Its featureset is designed for OOP and does not faciliate different programming styles.
And while we're on the topic, Perl has pretty much everything both Python and Ruby have (and better Unicode support, to boot), though it's wrapped in syntax and idioms that most Pythonistas and some Rubyists find distressing.
Because Java sucks ;)