[michaelochurch]

Java culture (IDE-dependence, AbstractFactoryVisitorFactory patterns, Maven and XML monstrosities) is hideous. It's based on the idea that reading code is a lost cause. You can no longer trust code, so you need all these wonky tool configurations to compensate for the fact that you're trying to make an army of inept programmers build something that is (unless it fails) going to become the next generation's legacy bloatbomb.

[eranation]

I think the issue is that there is no such thing as Java culture, there is Enterprise culture which is responsible for all that you said above. But there is a start of a new "Java culture" which is encouraging, see what Google did with Guava, see the Java version of Play framework, even Spring framework 3+ is not that bad, no XML, all annotations, JPA is nice as well. Look at stuff done by Yammer, Twitter, Google and other Java/Scala based companies.

I wouldn't go and dismiss one of the most popular Enterprise frameworks, as a user of Spring / Hibernate for last 7+ years, it makes a lot of sense to me in the enterprise context, just like Ruby on Rails and Play Framework makes sense to me in the SaaS contect, for instance, having Play framework with a Spring module is a nice interim solution for bringing newer technology to the enterprise world.

It all depends on what you need to be doing. Spring is great for a large enterprise app, that have long lifetime, needs to connect to legacy stuff, needs common enterprise integration patterns etc.

Also if you check SpringSource latest stuff, you'll find out they are investing in lot's of cool new things, e.g. the scripted text editor - (https://github.com/scripted-editor/scripted/) and are influenced a lot by the Rails, Django, Node.js and Play communities.

The enterprise world is not that stupid, it's perhaps just a bit behind but it's still making tons of money from it's software, in billions, and it's more likely to be written in Spring / Hibernate than with Rails / ActiveRecord.

Just give it some time and patience.

[twistedpair]

Always love all the Java hate on ycomb. I'm not sure how a dynamically code hotswapping Ruby app with 10k classes and 1k domain objects works, but I suspect many of the same patterns emerge as have been solved in Java.

[michaelochurch]

Large single programs should almost never exist. There are exceptions, but the typical bloated business app is not one of them.

Managerial idiots like overambitious single-program IT projects because it makes it easier to allocate "headcount" when the programmer-to-program relationship is inverted (many programmers to one program, instead of the right way, which is one programmer working on many programs).

The truth is that every programming approach fails you when you do this. For one example, static typing fails on versioning issues and compile-speed problems, while dynamic typing ends up with silent failures and integration bugs.

There is one case I can think of where large single programs work, and that's in the database space. You have a lot of requirements (transactional integrity, concurrency, performance in a heterogeneous world) and they all have to work together. It has also taken decades for some of the brightest technical minds out there to get it right.

[hythloday]

Large networks of small programs fail in exactly the same way: static typing fails on versioning issues (an RPC call carries inherently less type information than a function call) and compile-speed problems (compiling 200 small services can take just as long as compiling one behemoth). We also don't have mature tooling for the "network program" you're talking about.

I don't know what your metric of "large program" is, but AAA games often weigh in at 10-100 million lines and are typically architected as a single large codebase with auxiliary small programs, and doing them any other way is not a sensible approach.

[twistedpair]

WADR, most enterprise billing, invoicing and accounting systems are also such cases where it is not desirable or practical to sprinkle the business logic across dozens of silos.

[netghost]

In languages like ruby, python, and probably to some degree go, you tend not to need as many classes. Things like Factories, Adaptors, and Proxies tend to disappear or become pretty trivial.

Eventually programs written in these languages can grow huge, but it takes longer, and the preference tends to then be to break a program down into smaller libraries (gems, eggs, etc.) and separate applications that communicate with each other.

[wheaties]

Not all of Java culture is like this. There's a ton of really great code out there. Take a look at any Android library. There's no damned Spring anywhere.

Or switch to Scala like me.

[michaelochurch]

I agree with you. I don't think there's one Java culture anymore. So what I mean by "Java culture" is POJOs, Factories, Maven, and IDE-dependence. Commodity-developer, large-single-program nonsense that corporations invented to compensate for mediocre engineers. Android is bringing a lot of good engineers into Java, and Scala and Clojure are also bringing a lot of good people into that ecosystem.

I think the issue with the enterprise, large-single-program Java world is that there isn't a feedback cycle. Curious, motivated engineers hate that kind of environment because they want to see things actually work. Clojure and Scala have the REPL, but large-program Java development doesn't.

[fusiongyro]

> It's based on the idea that reading code is a lost cause.

I would argue that it is based on the idea that there's going to be too much code to read it all, and that knowing you need to use something shouldn't automatically entail knowing how to create something.

[factorialboy]

In our defense, have you tried reading Java code?

[michaelochurch]

Wait, people actually read Java code? I thought that's what IDEs were for.

For a serious response, I've seen tons of Java code of varying quality. Most was worse than horrible, but I have seen well-written Java. The Java code for Clojure is excellent, for one example. Most corporate Java code is indistinguishable from profanity.

[edwinnathaniel]

Ditto with any other language (especially JavaScript...)

[twistedpair]

I grant you that. I try to abide by everything in "Effective Java 2" but some of the code I come across in my daily work makes me ill. I wish I could say such code was uncommon, but someone will always try to use a hammer as a screwdriver if it still compiles.