Why Java sucks

[Zeroth]

Another reason Java sucks: no first class functions.

Which is prettier:

code:

static class MethodHolder{      static randomMethodVerb(int n){               return n*n;      } }

vs

code:

def randomFunctionVerb(n):       return n*n

For every possible standalone function, you need to have a class act as its escort. Its very annoying when I just want to write simple text processing code. I need to wrap it in so much extra annoying syntactic... well, effluent would apply. Even in C++ functions are first class citizens. In Java, they are all "methods". Some people may see it as a feature, but really, how could you? [/code]

[rizzix]

That (example of yours) does not necessarily demonstrate first-class-functions.

[DemonWasp]

This, like a lot of the other "deficits" of Java, can be both: problem and feature. Yes, some abilities (operator overloading, first class functions, pointer arithmetic) can be very powerful when used correctly. They can make code more expressive, faster, or better.

However, all of these are easy to abuse. Operators can be overloaded in nonsensical ways (I've heard of the + operator meaning "next" in a List implementation). Pointer arithmetic can be buggy and incredibly difficult to fix. Functions outside of classes can devolve rapidly into the horrific world of C: where there's NO Object-Oriented programming (note: OOP isn't the be-all-and-end-all...it's just way better than the alternatives for a lot of applications).

What all this means is that the code is easier to maintain and to work on. The language denies you the use of some of the worst antipatterns and programming kludges. Yes, it also prevents you from using it in certain ways, but does so to prevent that idiot sitting next to you from using it incorrectly.

That said, operators should be overloaded for a lot of the basic classes. Integer, Double, Float, etc should all have the operators + - * / overridden (it only makes sense), much as String has + overridden. Not doing that makes no sense whatsoever to me.

[Zeroth]

Maybe not neccesarily, but now, with that function, I can pass that around to other functions as variables, like:

code:

def iter(lst, func):     for item in lst:            print func(lst)

Of course theres this, which is gone in Python 3:

code:

map(func, lst)

The fact is, a first class function is one where you can refer directly to a function as if it were an object or variable, and even alter attributes of a function. But thats not my point. My point is that Java is so very paranoid of letting functions go around on their own. My friends and I joke that Java is "function-ist". Yes, not very funny. Its not necessarily that it prevents bad code. Its that it makes the code harder to read, since theres all that cruft surrounding static functions. I'm all for classes, but I don't use classes for every little thing I do. That is very much a case of, "If you only have a hammer, the whole world looks like a nail." Its also why I don't believe Java should be taught to first year students. It confuses the hell out of people when they get to C, or Scheme/Lisp, or anything where functions are very much first class citizens. Going the other way, however, is much better, in that the students recognize why certain things exist in Java, having been bit in the face by gotchas in other languages.

Personally, I prefer languages that don't nanny me in my coding. If I'm going to shoot my foot off, I'll find out in my unit tests I write before I do any code. Its just good common sense.

The problem with Java being "easy" to work on, is that it causes a kind of coding inertia, due to its verbosity. Someone writes 500 lines to do something it takes 10 lines to do in Python, Perl or Ruby. Now, when its discovered that theres a bug in the code, a severe one, or it doesn't work to specs, its a lot easier to throw out the 10 lines, vs the 500 lines. If there is a fundamental flaw of the logic or the interaction of the objects and methods, then it would take a lot of severe kludging to fix. You can see what'll happen from there. But that is personally my view. Everyone is entitled to theirs, and if you feel more productive and safer in Java, you are welcome to it. If that sounded snarky, I don't mean it as such.

-Zeroth[/b]

[Vermette]

heh, you might like the following essay:

http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html

[Zeroth]

(I've read that before, but thanks. Its a brilliant essay, yes. )

[wtd]

The other thing about short codebases as opposed to long ones...

You can throw it out and start again.

[DemonWasp]

There's nothing to say that you have to write ungodly amounts of Java to do stuff that can be done in 10 lines. You'll need more code, yes, but nowhere near 500 lines. And you may have less explicit error-handling, or be even further removed from the machine.

My preference is both for the language to "nanny" me, but also for it to do the same to other developers. I know I tend to write good code (provided I know how), but I don't trust most other developers to do so. After seeing some of the code other people release into production (and here I speak of Javascript, no less), I fear having to deal with other people's code written in C/C++.

I'd also agree that Java isn't a good choice for a first language, and perhaps not even a second language. It's very useful in the corporate environment, or when you're wanting to write larger projects on your own. A lot of the design decisions don't make a whole lot of sense until after you've learned a couple of other languages. It's probably a fantastic idea that UWaterloo is changing out Java in the first-year courses for Scheme and similar.

Perhaps a bigger problem than any language differences is developers who write bad code, or try to use the idioms of one language in another. They're altogether too prevalent, and it's impossible for the language to correct their incompetence - Turing, HTML/CSS/JS, Visual Basic, Java, C++...nothing can correct stupidity.

Some languages just do a better job of preventing it from becoming monumental.

[Zeroth]

DemonWasp @ Fri Jun 13, 2008 11:24 am wrote:

[snip]nothing can correct stupidity.

Some languages just do a better job of preventing it from becoming monumental.

I had to quote that. That is so very true. Thats what Java does well, it keeps people from cutting off their feet without encapsulating the cutting verb in an Attacker object.

I don't neccessarily think Java sucks, just that its way overused for its minor advantages. I just dislike that a much better designed language, which had a VM before Java did, has nowhere near the "popularity" of Java. The benefits of having a very large marketing budget, hmm? (Just for reference, the language I'm talking about is Python. Started in 1991, vs 1994 for Java!) But I guess thats a good thing. Typically experienced Python programmers are of higher calibre than "Java School" trained programmers, as you need to learn Python on your own, instead of it being crammed at you. That in turn indicates initiative, which is a good thing for a programmer to have.

[rizzix]

Zeroth @ Fri Jun 13, 2008 9:52 am wrote:

Personally, I prefer languages that don't nanny me in my coding. If I'm going to shoot my foot off, I'll find out in my unit tests I write before I do any code. Its just good common sense.

Just because you don't like a language to "nanny" you around, does not mean the language sucks.

Zeroth @ Fri Jun 13, 2008 9:52 am wrote:

The problem with Java being "easy" to work on, is that it causes a kind of coding inertia, due to its verbosity. Someone writes 500 lines to do something it takes 10 lines to do in Python, Perl or Ruby. Now, when its discovered that theres a bug in the code, a severe one, or it doesn't work to specs, its a lot easier to throw out the 10 lines, vs the 500 lines. If there is a fundamental flaw of the logic or the interaction of the objects and methods, then it would take a lot of severe kludging to fix. You can see what'll happen from there. But that is personally my view. Everyone is entitled to theirs, and if you feel more productive and safer in Java, you are welcome to it. If that sounded snarky, I don't mean it as such.

First, I highly doubt you'll get a 50:1 (Java vs others) lines-of-code ratio, so there's a bit of over-exaggeration there. Unless of course you are an extremely naive Java programmer. Secondly, I'd like to say that Java enforces you to think before you code whereas other languages (like Ruby, Python, etc) do not enforce this for various reasons, including the ones I'm about to mention.

Java forces you to think before you code. It enforce this at least though two very effective ways I can currently think of: library design and strong static typing.

Most Python/Ruby programmers dislike Java due to its complexity of library design. That is, well, their opinion, but it would make sense coming from such a background. Java programmers do not find the design overly complicated. In fact we like Java for the fact that it is a simple language (and hope that it continues to remain simple), so the only thing we'd need to focus on is software design. The Java libraries (standard and others) are usually well designed and most of these designs have been studied and generalized as "design patterns" -- another word/concept most Java-bashers dislike. These "design patterns" are not a guideline that all Java programmers must follow but rather they are a guidelines for coming up with one's own innovative design. I would like to further add, that it would be naive to use Java as a scripting/agile language. The agile frame of mind does not work well with Java at all. If you did approach coding in Java from this perspective you would eventually end up rewriting large amounts of code from scratch, rather than simply refactoring it toward improvement.

I don't suppose I need to say much about static typing. Providing a degree of proof of correctness before execution certainly enforces the think-before-you-code principle.

[rizzix]

Languages like Ruby or Python do not nanny you around. Thus you are left alone to code naively or shoot yourself in the foot till you've realized what you've done. Which eventually leads to the rewriting from scratch nonsense.

[r691175002]

I do agree that first class functions would be nice. Too often you have to wrap a single function in an inner class for an event listener/similar.

[Tony]

rizzix @ Fri Jun 13, 2008 4:03 pm wrote:

I don't suppose I need to say much about static typing. Providing a degree of proof of correctness before execution certainly enforces the think-before-you-code principle.

While better than no proof at all, static typing isn't much of a test. In fact, it could give a false sense of correctness. Static typing will say that the result of 2 + 2 is an integer, while a correct unit test of 2 + 2 = 4 (that would have to be written now anyway) would have the same implied.

Though in a corporate world run by business/management type of people who'd skip over testing in favour of deadlines, I suppose there's a certain advantage in forcing minimal testing via strong types.

[rizzix]

Static typing is not a test of values but a test of types. It provides proof of correctness for more abstract relationships.

[Zeroth]

Rizzix, I never mentioned the libraries. I find the libraries to be very nice, well-organized, and well documented. However, I'm talking about the language itself, not the quite excellent tools, libraries, and documentation around the language.

Different types of programmers like different kinds of languages. If I'm doing an application, I may consider Java, but for most of my use, which right now is computer science research, Python works perfectly well. Its rapid development design allows me to sit down, code up an implementation, run it quickly through some peer-checks to make sure the code is right, which the designed in readability really helps with, then run the code. If I were to do this in Java, there would be discussions, and planning about the object model, about relationships... when I want to get some work done. No offense, but when I'll be hiring programmers, if you were to reach for Java as the first language to solve a problem thrown at you within time constraints, I'll shoot you in the foot. There are advantages and disadvantages to Java, and it has its uses.

But the point is, it can achieve its purported goals... and LOOK NICER while doing so! I think that was a lot of what wtd was trying to get at.(Correct me if I'm wrong, I'll retract that statement, lol).

Oh, and on the topic of "static checking", where I am not an expert in any way, I'll refer you guys to this superbly written blog post: http://www.coderoshi.com/2007/09/5-reasons-static-typing-sucks.html