I don't think Java is as bad a language as some people think it is.
Personally I write very concise Java code that is full of functional ideas. Tools like Guava, Spring and language features such as static imports, as well as just having the value that verbosity is a problem, can lead to Java code that is fast to write and easy to understand.
When people are doing rapid prototyping in a REPL, I'm writing unit tests in my IDE, and rather than scrolling off the screen and into oblivion, these tests are incorporated into my project right away and always watching my butt.
If you want a REPL, Groovy is great. For instance, one time I was trying to figure out what was going wrong with a Hazelcast cluster, and I was able to create a Hazelcast client in Groovy just by puncing in the maven coordinates for Hazelcast and it was a lot like working with the MySQL or mongodb db shells.
I think the main problem with Java is the total complexity of the ecosystem, and the fact that it requires wisdom to use well more so than intelligence.
Personally I have been bouncing back and forth between Java and other programming languages for years. I was programming it back when it was in beta, and back then it took me about a year of experience to be able to write reusuable OO code that was worth reusing.
More recently I got back into with two gigs for companies that had huge maven systems (30+ projects) and it was stressful a while, particularly when a large number of SNAPSHOT version releases, my internet connection was slow, and everything was half-baked.
In a situation like that where you have to get on top of everything that's specific to a large codebase, you've got a 20-minute build process, no real project management (in one place the project manager quit the team after she got bitched out by my boss) and, if you're really unlucky, you're the last person to touch the code before it goes to QA, it's stressful.
When I went back to coding for my own account, I read the maven documentation from cover to cover on my nook when I was working out at the gym and now my build process is faster than my car can drive the quarter mile and I intend to keep it that way.
I think it is tougher for new programmers to get on board of it and a lot of the problem is that companies are trying to look for 10x programmers when they really should be building a 10x organization.
For instance, a 10x change can be had by getting a 20 minutes build process down to 2 minutes. It's not science fiction. Sometimes team members and the boss will say that this "isn't a customer requirement" or "you're not being a team player" if you want to speed up the build, but I know the customer wants the job done quickly and the job done right, and speeding up the build process 10 times is the fastest way to attain either of those goals.
> When people are doing rapid prototyping in a REPL, I'm writing unit tests in my IDE, and rather than scrolling off the screen and into oblivion, these tests are incorporated into my project right away and always watching my butt.
THIS!
Many programmers tend to prefer the cowboy style of coding: jump to their favorite IDE/editor and code straight away with less consideration of anything else (productive workflow, etc).
But you're right, the initial complexity (complexity of the ecosystem) to setup a Java project is a world of hurt for people who have limited experience/knowledge vs Python/Ruby ecosystem.
With Java, it's more of a love-hate relationship probably because the language has been around for far too long :).
Love it because it's stable, well-known quantity, have standards (can be a double-edge sword) that many people have to support, and awesome collection of tools and libraries that no other platform/language ecosystems can match.
Hate it because setting things up (IDE, projects, etc) and writing certain part of code could be a bit verbose/more work.
PS: I also go back and forth between various programming languages (JS+Python mostly)
The major issues for a lot of people are simply cosmetic clutter: having to specify types everywhere rather than some basic type inference, for example.
Other problems are deeper: no first-class functions, no tail-call recursion support in the JVM (Clojure has a hack to deal with this), no map/fold/etc. equivalents that can potentially aid with parallelization. I think 1.8 addresses some of these.
Personally, I can live without the modern language niceties. I would really, really like type inference though. Oh, and unsigned ints too.
Java does have its own form of type inference that revolves around Generic functions and once you make peace with it, life isn't so bad. Rather than writing
var xyzzy=new ArrayList<Foo>();
you can write
List<Foo> xyzzy=Lists.newArrayList();
Similarly, the lack of first class functions can be worked around by various means. The Guava toolkit contains map/fold and other functional operations, and when worse comes to worse you can write
for(Thing that:things)
fn(that);
In cases where you might be tempted to do something that's more verbose than if you tried to do it the cool way.
There is a lot to like about JDK8 but unfortunately I'm coding to JDK6 these days instead of JDK7 because it's a waste of time dealing with trouble tickets caused by people who are running the wrong Java version and don't know what is going on.
Personally I write very concise Java code that is full of functional ideas. Tools like Guava, Spring and language features such as static imports, as well as just having the value that verbosity is a problem, can lead to Java code that is fast to write and easy to understand.
When people are doing rapid prototyping in a REPL, I'm writing unit tests in my IDE, and rather than scrolling off the screen and into oblivion, these tests are incorporated into my project right away and always watching my butt.
If you want a REPL, Groovy is great. For instance, one time I was trying to figure out what was going wrong with a Hazelcast cluster, and I was able to create a Hazelcast client in Groovy just by puncing in the maven coordinates for Hazelcast and it was a lot like working with the MySQL or mongodb db shells.
I think the main problem with Java is the total complexity of the ecosystem, and the fact that it requires wisdom to use well more so than intelligence.
Personally I have been bouncing back and forth between Java and other programming languages for years. I was programming it back when it was in beta, and back then it took me about a year of experience to be able to write reusuable OO code that was worth reusing.
More recently I got back into with two gigs for companies that had huge maven systems (30+ projects) and it was stressful a while, particularly when a large number of SNAPSHOT version releases, my internet connection was slow, and everything was half-baked.
In a situation like that where you have to get on top of everything that's specific to a large codebase, you've got a 20-minute build process, no real project management (in one place the project manager quit the team after she got bitched out by my boss) and, if you're really unlucky, you're the last person to touch the code before it goes to QA, it's stressful.
When I went back to coding for my own account, I read the maven documentation from cover to cover on my nook when I was working out at the gym and now my build process is faster than my car can drive the quarter mile and I intend to keep it that way.
I think it is tougher for new programmers to get on board of it and a lot of the problem is that companies are trying to look for 10x programmers when they really should be building a 10x organization.
For instance, a 10x change can be had by getting a 20 minutes build process down to 2 minutes. It's not science fiction. Sometimes team members and the boss will say that this "isn't a customer requirement" or "you're not being a team player" if you want to speed up the build, but I know the customer wants the job done quickly and the job done right, and speeding up the build process 10 times is the fastest way to attain either of those goals.