Hacker Newsnew | comments | show | ask | jobs | submit login

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.




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.

-----


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.

-----


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.

-----


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?

-----




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: