When I write code, I want to solve a problem, not write a book--that's what documentation is for.
Whenever I code in Java, I always feel the language ends up working against me. To get from point A --> point B, the end result usually consists of having traveled through points C and D as well as having written a corpus of code whose length might rival that of War and Peace -- when working on a major project. Writing similar code in other languages, my LOC clock in at a fraction of the Java code. Personally, I've found the less LOC I have to deal with, the easier project maintenance gets, but that could just be me.
I don't think the practice of self documenting code limits itself to Java. If I choose descriptive names for my files, functions, classes, variables, etc., I can still convey the meaning of individual blocks of code and the entire project regardless of language.
Hopefully the people reading my code would be able to grok that a method called "openXMLConfigFile" exists to open the XML config file and all the code contained within does just that, hopefully.
Lack of an echo keyword.
When I don't want to use the debugger but just print a few things to console, System.out.println("x = " + x) is a real mouthfull.
Exceptions:
I end up with too many layers of indentation sometimes because of exceptions that I know will never be thrown anyway.
For example let's say you want to SHA1 hash something, you have a NoSuchAlgorithmException incase you are running on a JVM without a SHA1 hash function, which is something I know will never happen with my program.
I'll be leaving PHP as soon as PHP gets "Unicode Support".
The thing I hate the most about Java is that 2/3 of the time a junior programmer will write the wrong incantation when they open files, so Unicode characters will get scrambled. This gets missed by TimewastingDogmaticDevelopers (TDD) because they never write JUnit tests that read real files because they're too busy making mock objects. Instead, this problem gets discovered weeks or months after the fact.
I've never had Perl or PHP apps double-encode text that gets written to the database, but now it's on my checklist to check for double encoding whenever I smell a "bad smell" named Java.
While I can appreciate the author's experience - that learning lower-level technology gives on a great appreciation for the full stack and an ability to deal with leaky abstraction - I think he gets confused when he ties the lower-level implementation he's discovering with java's verbosity.
C is a lower level language that exposes a lot of stuff that's hidden in Java, but I've not read much C source code that makes me think it's too verbose. My experience with Java has contained far too many AbstractErrorCorrectingModalDialogueFactory classes for me to enjoy using it.
I agree the naming conventions / practices also contribute to the verbosity, but you would name the AbstractErrorCorrectingModalDialogueFactory the same way in any OOP language, if this name describes it best.
I don't mean to get into a language war here. the point here isn't that bad names make java into a poor language. My point is that the lower-level details the author is seeing are not due to java's verbosity. They're due to java being a lower level language than php.
though to respond to your assertion, I actually think @floppydisk got to my point in a much quicker manner than I could. I don't think I'd need to express such a thing in a more expressive language. I'm not talking about the naming convention, I'm talking about how Java forces you into a version of OOP that requires you to use a litany of "design patterns" get anything done. A more expressive language would be able to capture the same idea without the litany of java classes, interfaces, and generics that come with java.
Agreed. Once you use a language with type inference it's hard to go back to Java.
Java also lacks properties, which results in boilerplate getter/setters if you want to follow idiomatic convention (you could make all the member variables public, but your coworkers would probably shun you).
There are alternatives. e.g. a public final Property<String> Name = new Property<String>();
Where Property defines a .get() and a .set();
However, getters and setters are generally a code smell. It's better to be telling objects to do things rather than ask them for information. Modern Serialization & Injection frameworks no longer require getters/setters.
As the programmer, you wouldn't call getMap if you didn't know the return type
As the reader, this situation would be analogous to looking up the what map is, assuming it was declared earlier ... is a datamember etc.
something that might as well arise when typing..
private HashMap<Integer, String> map ;
then 30 lines later
this.map = getMap();
You would have to check javadocs or function header some time
If I wanted to see how everything works, why would I need the abstraction of a higher level language? Why not just code in direct assembly? Abstraction has a value and I think it's a waste of time that it takes so much boilerplate code to do routine things in Java.
after doing some ruby work recently which required reading a lot of undocumented code that could have used some major refactoring, i really began to appreciate java's verbosity. even the most poorly written java leaves behind tons of clues as to what is happening. with ruby, if there is no documentation and no tests, you're SOL.
that said, there are still tons of things about java that really get on my nerves...
PHP was very easy to use.... So I didn’t bother to understand the underlying mechanics. Java forced me to.
Same line of thought circa 1996
"Java was very easy to use.... So I didn’t bother to understand the underlying mechanics. C forced me to."
Same line of thought circa 1990
"C was very easy to use.... So I didn’t bother to understand the underlying mechanics. Assembler forced me to."
Abstraction layers are not the problem, however understanding what do to when they start leaking is the solution.
http://www.joelonsoftware.com/articles/LeakyAbstractions.htm...