`System.out.println` is ridiculous, and you're likely to use it many times unlike `public static void main`. Well, since there are only 2 of these I suppose you can simplify this to it's not hard to customize your editor to expand `sout` or something to that.

Java culture promotes long class names and method names, which are often neither unambiguous by prefix nor by initials, which are the 2 basic autocomplete styles (though really, I shouldn't allow the pro-Java argument to consider autocomplete at all, even a stupidly basic one).

Java culture (and to some extent the language itself, due to package-private) expects separation of classes within a project into multiple/nested packages, but package names are expected to be very long and there are no relative imports. And classes from third-party packages will also have horribly long names. New-file templates can help a little if you're willing to suppress "unused import" warnings.

The lack of support for "free functions" (outside a class) adds a ton of verbosity, if you can't fake them via dummy interfaces. Meanwhile, the fact that `this` is implicit makes the question of "what identifiers are in scope" almost as complicated as C++.

But yes, if you're paying attention, Java-the-language can be made somewhat nicer if you ignore Java-the-style (notably, many developers of Java itself are famous for doing this internally). But then you basically give up on the library ecosystem, which is the only reason to write Java in the first place. You can't even add interfaces retroactively!

Yes, I know they say "speed of programming isn't limited by how fast you can type", and it's usually true. But Java proves it can be bad enough to drop your cache.

> `System.out.println` is ridiculous, and you're likely to use it many times

No, you don't use it often.

You can use it as a poor man's debugging tool, but Java actually has very nice debuggers. You can use it as poor man's logging, but then you have pretty good logging frameworks. Or you can use it as application output, but then you probably want to abstract specific output stream away from most of your business logic code and use interface.

Java’s debug tools are first class and even this stubborn vim user knows to hand over the keys to Idea anytime I have to do anything in Java.

With that said I’m still a sout, puts, Printf, cout << developer.

So in that highly configurable and scriptable environment you can't create a macro like sout that expands to System.out.println, really?

Also, if it can't even import symbols automatically, then it sounds like a tool problem. Java is like one of the simplest languages, it has no fancy features, has sane imports, ultra-stable tooling, etc.

The point of an IDE is to improve productivity. And I think you just haven't seen someone who knows the ins and outs of an IDE fly while writing Java there.

My point is that "highly configurable and scriptable environment" is a much higher floor than other languages have. You don't need that to be productive in most languages; there are people who write serious code in nano or even notepad!

And what objective metric is there that prevents it from working in java? Because there are, in fact, people that write java in notepad, probably much more than those who write rust and go and swift there, combined.