I'm not sure how one framework developer's naming choice (a framework which by the way, needs to do some pretty meta things in regards to creating factories for other factories, and which is using the term "singleton" to mean something different than usual) is a criticism of an entire language.
You can come up with ugly names for classes in any language.
I think it speaks more to the community than the language (and arguably there is also no such thing as a community).
After years of consulting I can't remember how many times I've walked into an Enterprise Java Shop(TM) to find TemporalSystemLoadOrganizers, IntransitPredeterminedApplicationUtilitySources, MetaphysicalManipulatitiveQuantityDisorderRecognizers only to find out that at the end of the day these abstract-factory-driven-decorated-decoupled-dynamically-injected-frameworks tend to do such obscure/complicated things as "Update a user's first name" or "Show the last item the user has purchased"...
Again, not Java's fault and no question you can write very fast, beautiful and clear code in Java. I'm sure every language has specific warts and most of them probably reside more with the community than the syntax.
Right, it's not the fact that you can name things poorly in any language, it's that non-descriptive, overly verbose word-jumble vomit is built and presented seriously and without irony as common practice.
Either it's the people who write Java, or something intrinsic in the design of the language itself that drives people to write code in this extremely verbose way. I've always leaned towards the latter...
A bit of column A and a bit of column B. People who write Java are exposed to rampant overuse of design patterns when looking at examples of a) what the community considers Good Java and b) all over their internal projects. This is partially because Java lives, by design, in a Kingdom of Nouns and partially because there's just no good way in the standard language / library / toolchain to do some things without going really pattern heavy.
For example, assume I've got a list of students, and I want to show all the ones who haven't taken at least one exam, sorted by last name. Here's the relevant pseudocode in Rails:
That just flows from my keyboard as a Ruby/Rails programmer, is pretty much instantly comprehensible to other Rails programmers, and (while others might disagree with stylistic choices, variable names, or whether to use that weird &syntax to do the sort) would be considered "good enough Rails code to ship."
I will take the liberty of pasting my Java implementation into a gist -to avoid breaking HN:
A nice, svelte 38 line method, which will be reused via copy/paste a hundred places in my codebase.
Incidentally, at my previous Big Freaking Enterprise job, the user need "Make a page for a class where we can see all students who haven't..." would get quoted to them as "No problem, that will cost you $1,000. Are we green-lit to implement or do you want docs written first ($250)?", because the core logic I've shown you is the tip of the iceberg of how sucky that experience is going to be. We haven't even started with the XML files and annotations required to hook the new actions together yet. By comparison, as a Rails developer, in lieu of getting you to sign off on a $1,000 line-item to your next invoice I'm inclined to show you a totally working page and ask you "Is this what you wanted?" because implementing it is easier than talking about implementing it.
I don't want to play code golf with you, because I think your point is generally valid, but you can happily and idiomatically reduce the Java method itself to 10 lines with some sympathetic scaffolding from the other classes (this is actually how a lot of code in our game is implemented rather than some theoretical optimum):
public class Student implements Comparable<Student> {
@NotNull public List<Test> getTests() { ... }
@NotNull public String getLastName() { ... }
@Override public int compareTo(Student that) {
return getLastName().compareTo(that.getLastName());
}
}
List<Student> studentsWhoHaveNotTakenAtLeastOneTest() {
TreeSet<Student> studentsMissingAtLeastOneTest = new TreeSet<Student>();
for(Student student : getStudents()) {
boolean allTestsWereTaken = true;
for(Test test : student.getTests()) {
allTestsWereTaken &= test.isTaken();
}
if (!allTestsWereTaken) {
studentsMissingAtLeastOneTest.add(student);
}
}
return new ArrayList<Student>(studentsMissingAtLeastOneTest);
}
The point I'm (perhaps ineptly) making is not that Java isn't all that verbose (because it obviously is) - rather it's that you don't get much of a stack of abstraction by default. If you don't take the time to implement that abstraction, you're going to have a bad time, but if you do, it's not appalling.
It's not really dynamism so much as a functional outlook. Here it is in Scala (probably with a healthy number of syntax errors, and certainly with a whiff of inexperience):
You could get a similar amount of code in Java using something like FunctionalJava but that's not really a fair comparison, because patio11 is illustrating Java as it's spotted in the wild, and thus so am I. But with appropriate libraries and implementation patterns you can certainly write concise Java if you so choose.
It's the remnants of the late 90's early 2000's software development overengineering disease, so aptly captured in the mess that was J2EE.
Similar to "nobody got fired for buying IBM", the mindset was that "nobody got fired for building layers of abstraction just in case."
It's the culmination of the second system effect.[1] Without a pervasive unit testing culture, the big enterprise answer to "what if" is "let's add a point of flexibility here."
Obviously, people should be held responsible for building unnecessary abstraction layers like that. They waste time and are often wrongly abstracted, so when you do need to go in to refactor, you end up having to fight the pre-existing "what if" abstraction.
It's not about naming. This class actually does what its name says. That's the best part. The methods and their JavaDoc descriptions are pretty hilarious as well.
And it's not about the language per se. (You can write clean, simple code in Java, but you would have to write it pretty much from scratch.) It's about Java culture, which encourages this kind of stuff.
And yes, I had been a Java programmer for many years. I used to like the language at some point. But several integration projects made me like its culture less and less.
But let's be clear - this class isn't a part of the core library that developers would use everyday.
It's a part of a third-party open-source library that implements a "dependency injection container". It's a pretty abstract concept to begin with - of course it's going to need to do high-level, head-in-the-clouds-type stuff that on first glance you think you would never need.
You can come up with ugly names for classes in any language.