Java for Everything

I completely agree - but not all (or even most) of Java's verbosity is from repetition. The traditional example of `Foo foo = new Foo();` as repetition ignores the fact that `Foo` will not always be repeated as the first will often be an interface (or superclass) and the second will be an implementation, e.g. `Set set = new HashSet();`

> What features does Java have that you're saying help code convey more information or lead it to be expressed more clearly?

My comment regarding verbosity wasn't in comparison to Scala, I was thinking of Ruby, Python, Lua, et al (I'm a huge fan of Scala btw, but the post was on the benefits of Java versus dynamic languages). Anyway to answer your question with a few examples:

* Java's method signature gives me a lot of information, looking at `public int doStuff(String foo)` tells me the visibility, what it will return, and exactly what I can pass it - even to someone completely unfamiliar with the language. Looking at `def doStuff foo` tells me nothing other than how many arguments it takes (if you're familiar with Ruby you'll also know the visibility).

* Similarly when you see `return foo` you know (even knowing nothing about Java) that it's returning `foo` and that `foo` is the intended return value.

* Someone who's never read a line of Java in their life can look at `Map foo = new HashMap();` and know that `foo` is a map (and will most likely conclude it has Strings for keys and integers for values). If you've never coded in Lua and you see `foo = {}` you have no idea what that is (if you've seen similar in other languages you can make a good guess, but you don't know).

I'm sure you can cite that, but it feels wrong in this context.

That is, given the same language, or equally verbose languages, it may be true and applicable. But, if comparing a more verbose language to one that is less so, then the former will naturally yield a higher LOC count. But, does this mean it's more bug prone? There aren't any more logical constructs, flow control mechanisms, etc. The language simply requires more lines to express the same intentionality.

In fact, I wonder how a more verbose language would compare with a less verbose one if we normalized for some verbosity factor. So, let's say language A is twice as verbose as language B, such that when the LOC count of A is twice that of B, we consider them equal (call it the same "Effective LOC").

I actually wonder if, in this case, language B would have a higher bug count per effective LOC, owed to its terseness and/or reduced readability.

Unfortunately, it's also extremely expensive. That's not to say it isn't worth every penny in some situations, but I've gotten kind of spoiled by free development tools for personal projects. I'm glad the days of spending hundreds of dollars for things like C compilers are long behind me.

I agree that a really good AOT JVM would be very nice. It doesn't necessarily imply better performance however.

For some application domains, I would be happy to trade speed -- and even features -- for the ability to create a native binary with no dependencies.

This is one area where I find the Go programming language interesting. I prefer Java, but the lack of a good and free ahead-of-time compiler for Java that creates native binaries with no additional dependencies is a killer feature for some situations.

I have to disagree here. With just a little forethought, a good bit of the code can be reusable. For instance, your data access layer.

And, the more forethought you put into it, the larger the potential reusability. This doesn't have to be premature optimization. It's just a balance between getting it done as quickly/efficiently as possible while still making some sensible, fairly low-cost coding decisions for scalability. For instance, everything I write now is load-balancer ready. This was achieved largely through a simple library that understands its environment via a simple config directive, and proxies relevant calls (e.g. when pulling the client IP or checking whether the request is secure, it determines when to pull from the request headers stamped on by the load balancer versus invoking request.getRemoteAddr() or request.isSecure()). Of course, there are other coding decisions you make, but it's really not as much extra work as how you implement.

In any case, unless you're purposely writing completely nasty throwaway code, there is always some reusability, which typically makes starting from scratch in a new language a much weightier prospect than making some scalability enhancements to the existing base.