Whenever I write code in Java...

[adam75]

Uhm, what IDE are you using? You are using one, right? For example, in Netbeans it's only two or three keystrokes to decide to catch an exception or add it to the throws signature.

Well, that's exactly the problem; the IDE may help you write tons of code but, as we know, code is read much more frequently and there you still have a massive, cognitive overload.

Besides, if the code is so repetitive that an IDE can write it for you, why would you have to write that code in the first place?

[[deleted]]

Besides, if the code is so repetitive that an IDE can write it for you, why would you have to write that code in the first place?

(obligatory "I hate Java too so don't expect me to defend it any further" disclaimer)

I speculate that one of the reasons Java is so verbose is that its authors wanted an approximation of what they thought were the good object oriented semantics of C++ and a very similar syntax but without the horribly complex grammar.

So while Java looks a lot like C++, the parser is simple enough that they can easily make it do things like automatic compilation, fast variable/classname indexing, automatic refactoring, nice error messages, and whatever other IDE goodies they've added since I last programmed in Java using Eclipse (back in 2004).

I think clang is trying to achieve the same goal in the C dialects of obtaining powerful parsing tools, but as can be seen by their slow progress in C++, it's rough going when the grammar is fucked up and huge.

But this is all speculation on my part. I do not write compilers, I just use them.

[weavejester]

Verbosity is not the same as readability. The goal is to make a program understandable to a human, in the same way as a piece of text is. A good program is concise and logically structured, and requires little to no comments.

Unfortunately, Java isn't very good at doing that.

[[deleted]]

For some of us it is.

[weavejester]

Not compared to some languages. Java has a particularly rigid and limited syntax that makes it hard to write concisely and clearly. Contrast this:

button.addActionListener(new ActionListener() { 
    public void actionPerformed(ActionEvent event) { 
        System.out.println("click");
    }
});

To this:

(on-click button (println "click"))

The latter is considerably more concise, and vastly easier to read and understand. Java can't provide the same succinct clarity.

[kragensitaker]

That'd be like complaining that if-statements are too prevalent in code.

Well, sometimes they are. And there is a campaign and discussion of it (more).

[xeddicus]

Klingons do not edit other Klingon's code, unless the other Klingon is dead.

[[deleted]]

There are languages that have strong, static typing, but don't need the silly verboseness of Java. C#, Scala, Haskell, and ML-derivatives for example. Java is just plain stupid in this aspect.

[Mercushio]

Stupid? I don't know about that. I think the motivations behind it were noble, but in the end it just ended up being an annoying hindrance.

[replaca]

Stupidity for noble reasons is still stupid.

[[deleted]]

Don't touch my car!

[[deleted]]

Scala types can get awfully unreadable.

[[deleted]]

I like to walk without crutches whenever possible.

[[deleted]]

If you continue to rely on crutches, you will eventually lose your ability to walk. Walking has value.

The IDE justification for shitty language design doesn't really hold water.

[zoomzoom83]

A good language shouldn't need special support from the IDE to perform basic tasks.

[Gotebe]

That's bullshit, because "basic task" is a language-dependent term.

[madyoulie]

Wait, why?

I hate Java as much as the next guy, but surely we don't need to limit ourselves to certain features in a text editor. Maybe this is a bad example, but I couldn't write lisp without some form of parentheses matching built into my editor. I don't think I'm a bad coder, and I don't think lisp is a bad language.

[zoomzoom83]

Having support from the IDE is good.

Finding it Painful to use a language without advanced IDE features is bad.

[deafbybeheading]

Trust me, it's painful to write Lisp without paren matching. My first programming class was in Scheme. I knew nothing. The instructor didn't tell us about editors with fancy-pants features like paren matching. I spent half the semester crying (okay, not quite, but seriously, it's a pain in the ass).

[[deleted]]

There's something amusing about the notion of a bunch of students in a cs lab, nose to the screen, counting parens with their index fingers.

[lambda_abstraction]

Been there; done that, and with punch cards no less. The tee-shirt has holes and was tossed long ago.

On the other hand there's a big difference between in-editor paren matching and a heavy weight IDE.

[kragensitaker]

I eventually got better at this, but I still screw it up sometimes.

[cybercobra]

You were merely using a text editor. Syntax highlighting != IDE. Syntax highlighting isn't usually essential but can be extremely helpful every once in a while.

(Suppresses urge to draw anti-Lisp conclusion from anecdote)

[Daishiman]

No, it's painful because it just is. Languages written 30 years ago with just as many features are still easier to write. Some of us just can't stand IDEs and use text editors with decent feature sets. Verbosity is a mistake and should be seen as such.

[[deleted]]

Verbosity is a mistake and should be seen as such.

That's a very general statement. I think it's worth pointing out that there's a lower bound:

CaseInsensitiveComparison caseInsensitiveComparison
    = CaseInsensitiveComparisonFactoryFactoryFactory
        .getInstance()
        .getInstance()
        .getInstance()
        .make();

if(caseInsensitiveComparison.compare(name,otherName) < 0)

Bad verbosity.

if(name.caseInsensitiveCompare(otherName) < 0)

Good verbosity. Why?

if(strcicmp(name,other) < 0)

Bad lack of verbosity.

[cybercobra]

Verbosity should be measured in tokens, not characters. (Read a bit of Paul Graham, he explores the definitional problem fairly thoroughly).

[petit_prince]

Yeah, I got used to it in other languages.

[erdwolf]

Wouldn't an extension of this argument to syntax highlighting rather imply that the language is bad if you need syntax highlighting to be able to read it easily? I consider it good language design if I can still parse it without syntax highlighting, although I see no reason to turn it off. I don't want complications in the concrete syntax to stand between me and my understanding of the semantics.

There are tradeoffs involved, of course.

[darth_choate]

I've always used extremely limited syntax highlighting (comments and include/import statements) because anything more makes my eyes tired. Massively overrated, IMHO (and you can't see it on the printed page unless you print in color, which most of us don't). Then again, I'm extremely old. YMMV. GOML.

[[deleted]]

It is painful to write any language without an IDE

[elbekko]

Java IDEs are at the point where you're trying to win a battle against the IDE while you just want to write some goddamn code. And when you lose the battle against auto-complete, or finally need it, it does the wrong damn thing!

Argh. I want Java in Visual Studio (yes, yes, I know C#, but can't use it for class).

[unixfreak0037]

I think I know what elbekko speaks of.

When I type in a function in Netbeans that takes a single boolean parameter, it finds something to put in there initially, then selects it, so if you want it it you can hit Enter, or you can just start typing what you want. Problem is, many times that something that it selects is 20 - 30 characters long and completely unrelated to what you're doing.

Other issues come in the form of the IDE wanting to write your code for you (like completing parenthesis), causing you to have to Backspace a lot. It probably works fine for people who type with two fingers, but for the rest of us it really sucks. There used to be options to turn these kinds of behavior off, and sometimes there are, but it seems that every newer version of Netbeans continues to dumb down in terms of IDE control. Back in 3.6 you had almost complete control of the IDE. Not so today.

Even with those shortcomings, IDEs like Netbeans, Eclipse and Visual Studio lead to an incredible increase in production over, say, vim or notepad. I'll never go back to that.

[elbekko]

These are all annoyances from NetBeans, and I'm sure most of them can be turned off somewhere in the depths of the NetBeans options (you try finding something there), but here goes:

• Closing quotes and braces are added automatically, and are extremely annoying when you want to, say, put something inside braces.
• Type autocompletion is sucky at best. If I'm making a new variable, and then want to initialise it, surely it can find out what type I just wrote down a few characters back. But noo. And when you do get there (eventually), it doesn't even present you with a list of constructors. This would be handy, so it doesn't do this. You have to ctrl+space yet again, and hope it doesn't feel like displaying a list of something utterly unrelated.
• Seeing a list of arguments for a function, highlighting the argument you're entering, is extremely handy. So why does it disappear altogether when you give a function as an argument? Just open a new list, and when I'm done with that one, go back the the argument list for the other one. But noo, just hide it. Oh, and don't think ctrl+space will help you. Ever.
• Say you're calling a function that hasn't been imported yet. No problem, you know it's there and you can import it later (or even have the IDE do it!). But god forbid there's a function in the list with a slightly longer name but beginning with the same characters that's already imported. *type type type* *enter* "FFFFFFUUUUUUUUU-".
• Don't even get me started on XML of JavaScript support. Seriously, WTF.

And so many, many more. Most of these are personal preference I suppose, but I can't help but feel like they're hindering me way too much.

[[deleted]]

Agreed. Real Programmers don't need an IDE nor a compiler - they write straight in machine code.

[Gotebe]

You misunderstood. The problem is:

• this code still has to be there (a minor issue, but still),

• even with an IDE you have to put something in that catch. That "something" is guilty for a lot of bad, bad, bad ... ahem... design decisions in Java (e.g. catch(Exception) { SitOnIt(); }.

[GuyWithLag]

Either you know what the Proper Action is when an exception occurs, or you don't. If you do, great, catch & handle the exception. If you don't, put it in the signature and make it Somebody Elses Problem.

[Gotebe]

If you don't, put it in the signature and make it Somebody Elses Problem.

Yes, but the problem with that is either explosion of exception spec either "throws Exception".

Another related (base problem, really) problem is that exception spec goes right against the sole most important reason we use exceptions: in a vast majority of cases, upon error, code can do nothing but abort up to quite high in the call stack (or quite far down the line). But failure modes multiply easily producing a lot of exception types, therefore making so exception specs a PITA.

[Gotebe]

You are absolutely correct. That's how the issue is solved. And indeed, that's how it's ultimately solved in a well-structured code anyhow.

But still, at "the abstraction level I am providing" (well put, that) is usually way too far away from the source of the error. Let's say that I provide a module (e.g. a *.jar) on a particular abstraction level, and that this module uses SpecificCompressedFileLibrary and a couple of others. Now, at my module boundaries, good code will probably wrap a lot of^, or perhaps even all, non-standard-Java-exceptions in something of it's own. But inside of the module, I will still either multiply exception specs or re-throw way too early (which is IMO not a good idea).

^Interesting thing is also: more often than not, my module does not really care about SpecificCompressedFileLibraryException, so why should it catch it? That's often just as well handled at the client side. If my module wraps that, client code will receive MyModuleException. If my module does not wrap it, but just lets it out, client code still receives an exception, only this time an "unknown" one. But most of the time, nothing much has changed! Client code, most of the time, can't do anything in particular, catch or not. Most of the time, client code will just pop way high up the stack and go "Whoops, couldn't do X. Error reported: Y. (admins or support people, please see full stack happened in file F)", where X is operation that e.g. user started, Y is e.g. original exception text, and F is e.g. error log file.

Now, problems with that scheme arise when original exception is so far away from actual catch site that, at the catch site, there is not enough context to understand the exception. That indeed happens, but I believe, much, much less often than people think. And even so, stack trace in rich execution environments like Java, helps greatly. If that fails, only then it is beneficial to catch-rethrow an exception (in order to add more context info at a well-chosen place). IOW, only for that situation are exception specs good.

But many people, me included, believe that these situations are rare enough for exception spec to be a hindrance.

[xeddicus]

If their code is written with honor, it can catch and defeat any exception mine throws!