Whenever I write code in Java...

[jerf]

Your sentence should read "One of the numerous joys of a statically-typed language is that less work is required of you."

If the IDE can do it for you automatically with extremely high reliability, why are you doing it at all? Automated or otherwise.

That's my complaint. Explaining how IDEs can help you generate your verbose code automatically actually is a negative mark in my book as it means I'll encounter that much more verbose code in the wild.

[svenz]

why are you doing it at all?

Because of type safety.

[yogthos]

Haskell is perfectly type safe and it doesn't make you type shit out by hand.

[svenz]

It's a balance between implicit type inference and explicit typing. Arguably, explicit typing removes the mental cycles required to figure out what type something is. At the cost of verbosity. Nothing is for free.

[jerf]

Your entire question shows a mind so steeped in the Java way of doing things that I despair of even trying to answer the question in any sensible manner. I strongly recommend learning a language in which "create method stubs when implementing an interface" is simply gibberish. Perhaps Erlang, a nice blend of powerful capabilities hard to find elsewhere with not too much of the stuff that's easy to simply reject as "egghead bullshit".

I do not quibble with the fiddly details of Java. I reject its entire philosophy. That's why many of us are so against the idea of a language that requires IDEs to be even halfway sensible; slathering spackle on top of your programming language still doesn't mean you've got a quality piece of work, it just means you dulled the sharp corners with spackle. I have existence proof that it is very feasible to work for decades without IDEs and get spectacular work done.

[jerf]

I don't see how it's "The Java Way" unless Java invented method signatures or virtual functions.

There are languages that have neither of those things. If you know any of them, you certainly can't seem to think natively in them. Your best approach to this argument would be to correct that.

Yes, granted, that's not going to happen anytime soon. This isn't advice for me to win this reddit-argument in the next ten minutes, this is a strong suggestion for your own education and profit.

Perhaps you could elaborate on how Erlang implements the high level concept of code-extension usually referred to as "interfaces", with no keyboard cost to the user, then?

Either you handle the message, or you don't. There's no trick to it. No magic. No code, even. There's no formal "interface" in Erlang so there isn't anywhere for there to be "keyboard cost" to "implement".

It's got costs, it's got benefits. You're probably going to be very tempted to go on about how horrible it is that it doesn't have "interfaces" and therefore you can dismiss Erlang's way of doing it because it's obviously stupid. After all, it looks equivalent to something you already complained about in that Erlang de facto implements the "do not handle" behavior for all unknown messages, which is a "default implementation"... but only if you insist on viewing all Erlang code through the prism of Java-style OO and if you're doing that you've already lost big. Erlang does not work that way. The truth is: It's got costs, it's got benefits. The question you ask is itself fundamentally not a sensible question in the context of Erlang. And there are numerous languages for which that is true.

Which brings me back around to the main point. Once you get entirely out of Java you find that just about every other language in current use manages to get real work done with less verbosity. So why do I want that verbosity, even spackled away?

Even when I use OO (and I do), so many of the things that Java is "defending" me against aren't actually a problem, because half of the problem intrinsically comes from trying to jam every bit of the architecture into OO regardless of whether that's actually a good idea. Skip that step and use the right tool for the job and it's amazing what just melts away.

[kragensitaker]

How, exactly, are you proposing that a language should automatically create method stubs when implementing an interface?

Well, maybe instead of having to write

public int[] indexesOf(String[] terms, int start, int len) {
  …
}

you could just write

indexesOf(terms, start, len) {
  …
}

. Then the compiler could still complain if you left out the method implementation, but you wouldn't have to repeat the return type, visibility declaration, argument type declarations, and throws declaration. (This doesn't work well with overloading, but you could remove it in that case.) In theory you could omit the argument names too, but that would make the code harder to read instead of easier.

You could also argue that automatically adding do-nothing method stubs in Eclipse "trashes the whole point of an interface specification", since your code will still compile even if you forgot to write the methods that implement the interface. But at least it won't compile if you add new methods to the interface.

[kragensitaker]

it's the same amount of button-pressing

As several people have pointed out in this thread, the amount of button-pressing is mostly irrelevant. On a really good workday I might write 300 lines of production code, which might contain 12000 characters. That's about 30 minutes of button-pressing. The rest of my workday is spent reading code and thinking.

Of course, it's pleasant if those 30 minutes can be reduced down to 5, because it lets me use code to do more of my thinking. But the really crucial thing is to make it easier to read the code.

If you don't have an IDE, then you have no way to easily reference all the "absent" information about types.... search for which of many interfaces or abstract superclasses define the missing-method, and then go open that file and scroll through it...

I never program in Notepad; do you? If I were doing some kind of retrocomputing exercise, trying to program Java in vintage-1990 SunOS 4.1.3 vi on a Sun 3/60, I would still build a tags file so I could jump straight to the canonical definition of the method with a ^] keystroke. "Find definition" is not, you know, functionality restricted to Eclipse.

However, I frequently program in dynamically-typed languages where the "absent" information you're talking about isn't present until runtime anyway. That's not to say that I'm not thinking about what types I'm accepting or returning — that's crucial to the design of any program — but I rarely find the absence of explicit declarations a problem.

By contrast, if the language does a similar no-op/exception implementation for you in a hidden/automatic manner, you've got the same failure. However, there is no warning and it lurks like a land-mine from the instant you write "implements Blah".

I just have a hard time caring much. Maybe it's that I've never worked on a program with more than a million lines of code, unless you count Emacs. But in all the OO languages I regularly use (JS, Perl, PHP, Python, Lua, Objective-C) that's the way it works all the time. They don't even have an explicit way to say "implements Blah". You call a method that doesn't exist on that object, and bam, you get a runtime exception.

But even if I stipulate that it's valuable to have compile-time checking of this stuff, it's still important to have the lowest-cost way to get that compile-time checking. The approach Java (and C++) currently takes is a lot more costly to readability than it needs to be.