Nothing in the language forces verboseness for the sake of verboseness.
"public static void" has zero chance of containing errors. If you make a typo, it won't compile. It's not code, it's just "stuff". It doesn't translate to code. It doesn't "do" anything.
If you really can't learn to look past the "stuff" into the code, get your editor to hide it from you if you must.
Using "public static void" as an argument is almost as ridiculous as people who cite the lines of code needed to program HelloWorld.
Verbosity in a language should be measured in terms of actual code that does stuff. Not characters in source code.
For example, would you consider Basic with line numbers to be a verbose language since it has a number at the start of each line? Well no, because those numbers aren't code.
Another example:
Regexps are extremely terse and compact. Would you rather debug regexps, or java code? Which is easier to work with? Is it easier to make a mistake and introduce a bug in a regexp, or in java code?
The argument that less lines/characters = less bugs is not a good one.
It is verbosity. It's less harmful than some other instances because as you note it's extremely unlikely to cause bugs, but it's still noise that detracts from readability by obscuring the code that's actually relevant to the task at hand.
Would you rather debug regexps, or java code? Which is easier to work with?
If the regexp is expressing a concept that would otherwise take 20 lines of ad-hoc string processing in Java, I'll take the regexp.
If I'm looking at code, the "public static void" doesn't detract from readability at all. I would much rather see "public static void" than some new 'less verbose' &$%||foo|| stuff I have to look up. I find it much easier to read words than characters.
It's a wonder anything works in some of these new 'unverbose' languages, where a 'concept' is a single character, and a single char typo can mean you've suddenly got a bug you have to go find.
Verbose:
1 : containing more words than necessary
: wordy <a verbose reply>; also
: impaired by wordiness <a verbose style>
2 : given to wordiness <a verbose orator>
The word has a definition and you're either ignoring it to suit your point of view, or you don't know what it means.If you want to argue that there are good kinds of verbosity and bad kinds that's fine, but don't try to make up your own definition and expect anyone to buy it.
I agree though, it's perhaps not the best word to use.
Use what you enjoy using though. But please don't buy the FUD about verbosity.
You don't regexp's compact syntax. That's fine. You would have a point if you say that its more readable, let's say:
1: EXACT <a>(3)
3: PLUS(15)
4: ANYOF[ab](0)
15: OPEN1(17)
17: EXACT <cd>(19)
19: CURLY {0,1}(23)
21: EXACT <s>(0)
23: CLOSE1(25)
25: END(0)
than/a[ab]+(cds?)/
but it's much easier to introduce a bug in 20 lines of Java code that deals with an ad-hoc parsing than in a regexp, specially if you have to change the pattern.
Verbosity is a bad thing, because it can cause bugs etc. But that's not what Java is.
"private static void" is just boilerplate. It's stuff you type to get what you want, but it can't really be considered verbosity.
Mine:
Not verbose:
puts "Hello, world"
verbose: public class Hello {
public static void main(String[] args) {
System.out.println("Hello, world!");
}
}The 'verbose' one, I read as ...println("Hello, world!")...
Perhaps I'm not normal, but I 'see' those code snippets to be identical in terms of code.
Lets face it, we're never going to be bound by typing speed, and as I say, there's no chance of getting a bug into that 'verbosity' in java. So the only real issue is down to taste, which is up to the individual.
Also, have you seen those studies that show that everyone has a number n, and every n lines, you make an error? If you're writing 3n lines in Java for every n lines you write in $LANGUAGE, you're making 3 times the errors.
Try and make an 'error' in the phrase 'public static void'. See how well it compiles if you mistype 'public' as 'pubic'.
If you're not able to read the code well, then that's one thing (Learn to read code better). But don't spread the misinformation about errors. And no. You're not writing 3 times as much code unless you're an idiot. LOC in Java is pretty much the same as LOC in python for example when written properly.
It's not that you'd make errors in typing, of course your compiler will check those. It's that code you don't write is bug-free, and every line you do write has a non-zero chance of containing a logic (not syntax) error...
But anyway, it's very easy to write 3x LOC in Java. If you don't write much smaller Python code, you don't know how to code in Python. I can't think of a single task (mind you, I'm a Rubyist, so I very well could be wrong) that would take less in Java, and even ones with identical LOC, you still have things like
BufferedReader myFile = new BufferedReader(new FileReader(argFilename));
vs myFile = open(argFilename)