One problem with Java is the 15+ years of bad taste. Design patterns are "revenge of the not-nerds". It's "I don't know what a monad is and don't care to learn, but I'm going to make you feel the way I do when I see math by renaming the sine function to VibratorVisitorFactory."
Moreover, Big Software is generally a bad idea. There are occasions where large programs are a good idea, but the default should be small, composable units. Scripting and batch jobs aren't "baby coding". They should be the default unless you need a long-running server process. Most programs (over 90%) should be doing one thing and doing it well. The problem is that people don't code this way because it's better for enterprise managers' and architects' careers to say they oversaw gigantic, overarching software projects.
I've actually noticed that data scientists, while their line-by-line coding skills aren't as good as a professional software engineer's, are usually much better designers (and far better communicators) than Java engineers. Sure, R is janky and Python has ugly corner cases, but data scientists write programs to do specific tasks and generally are good at keeping code small (because they have a personal responsibility for the code-- if they can't read it, it's basically lost-- not experienced by "architects" who can hire maintenance engineers to clean up their messes). You don't see the enterprise "software for software's sake" problem.
I've noticed that the combination of math and communication skills is pretty well correlated with producing clean designs and code. Data scientists probably have those skills more often than programmers, but I'd argue that it's the skills rather than the culture that account for the difference you are seeing.
Moreover, Big Software is generally a bad idea. There are occasions where large programs are a good idea, but the default should be small, composable units. Scripting and batch jobs aren't "baby coding". They should be the default unless you need a long-running server process. Most programs (over 90%) should be doing one thing and doing it well. The problem is that people don't code this way because it's better for enterprise managers' and architects' careers to say they oversaw gigantic, overarching software projects.
I've actually noticed that data scientists, while their line-by-line coding skills aren't as good as a professional software engineer's, are usually much better designers (and far better communicators) than Java engineers. Sure, R is janky and Python has ugly corner cases, but data scientists write programs to do specific tasks and generally are good at keeping code small (because they have a personal responsibility for the code-- if they can't read it, it's basically lost-- not experienced by "architects" who can hire maintenance engineers to clean up their messes). You don't see the enterprise "software for software's sake" problem.
The result of Big Software tends to be Java Shop Politics, as described here: http://michaelochurch.wordpress.com/2012/04/13/java-shop-pol... . It's not the fault of Java. It's just a bad way of writing software.