Why I Like The Verbosity of Java
Java is too verbose, they say. You can find comparisons of Hello World programs that take 2 lines in ruby and 10 lines in Java, and in order to read a file you need 20 lines in Java and just 1 in php.
Even though the examples are often exaggerated (for example counting imports), it is true Java programs requires more lines of code. But this is not a bad thing at all. On the contrary – it is something I actually like. In fact, it is not about the verbosity of the language – apart from anonymous classes-insteadof-closures, there is nothing else that the language is too verbose about. It is about the core libraries. So – I like the way the core libraries are written in terms of verbosity. Two examples:
- take the java.io. package. Reading and writing files, streams, etc. It is a bit hard to graps, and in the beginning you copy-paste long snippets of code to simply read a file. But it forces you to understand the abstraction of streams and readers. Other languages have simply:
var contents = readFile("path") Cool, but you are never forced to understand how the I/O management works. What happens if reading fails? Is partial reading of the file sufficient for you? Can you nagivate the file? Should you close resources or they are automatically closed? You don’t need to answer these questions for a hello world program, but you will need to know about them pretty soon. And the less-verbose languages hide them from you and postpone this “abstraction revelation”.
- the servlet API. At first it looks to have some hairy classes and interfaces. But soon enough you realize how the whole thing works – not only in Java, but the general lifecycle of an http request. Because you need a Servlet object, and request and response objects, and output streams to write to, you understand the whole request-response cycle. I have a personal example here. I’ve been writing PHP for one year (in school). Then one month of Java and servlets made it completely clear for me how the whole thing works. PHP was very easy to use –
$_GET['foo'], session_start() and a bunch of HTML in between. So I didn’t bother to understand the underlying mechanics. Java forced me to.
You may argue that – fine, it forces you to learn these important concepts and abstractions, but it should also give you an easy way to acomplish things. But if the core libraries themselves had these options, all the tutorials would show these options, and the lower-level APIs would be forgotten. So the solution is – 3rd party libraries. Apache and Google give you these. With guava and apache commons you have all these one-liners. FileUtils.readLines(..), Joiner.on(",").join(array), etc. But you don’t start with these libraries, and you learn how things function on a slightly lower level – a level that you will be required to know anyway.
Java is too verbose, they say. You can find comparisons of Hello World programs that take 2 lines in ruby and 10 lines in Java, and in order to read a file you need 20 lines in Java and just 1 in php.
Even though the examples are often exaggerated (for example counting imports), it is true Java programs requires more lines of code. But this is not a bad thing at all. On the contrary – it is something I actually like. In fact, it is not about the verbosity of the language – apart from anonymous classes-insteadof-closures, there is nothing else that the language is too verbose about. It is about the core libraries. So – I like the way the core libraries are written in terms of verbosity. Two examples:
- take the java.io. package. Reading and writing files, streams, etc. It is a bit hard to graps, and in the beginning you copy-paste long snippets of code to simply read a file. But it forces you to understand the abstraction of streams and readers. Other languages have simply:
var contents = readFile("path")Cool, but you are never forced to understand how the I/O management works. What happens if reading fails? Is partial reading of the file sufficient for you? Can you nagivate the file? Should you close resources or they are automatically closed? You don’t need to answer these questions for a hello world program, but you will need to know about them pretty soon. And the less-verbose languages hide them from you and postpone this “abstraction revelation”. - the servlet API. At first it looks to have some hairy classes and interfaces. But soon enough you realize how the whole thing works – not only in Java, but the general lifecycle of an http request. Because you need a Servlet object, and request and response objects, and output streams to write to, you understand the whole request-response cycle. I have a personal example here. I’ve been writing PHP for one year (in school). Then one month of Java and servlets made it completely clear for me how the whole thing works. PHP was very easy to use –
$_GET['foo'], session_start()and a bunch of HTML in between. So I didn’t bother to understand the underlying mechanics. Java forced me to.
You may argue that – fine, it forces you to learn these important concepts and abstractions, but it should also give you an easy way to acomplish things. But if the core libraries themselves had these options, all the tutorials would show these options, and the lower-level APIs would be forgotten. So the solution is – 3rd party libraries. Apache and Google give you these. With guava and apache commons you have all these one-liners. FileUtils.readLines(..), Joiner.on(",").join(array), etc. But you don’t start with these libraries, and you learn how things function on a slightly lower level – a level that you will be required to know anyway.
I do too, like the verbosity of java, reading source code gives comprehensiveness to the application.
Good article! In fact, I’ve just subscribed to your RSS channel, please keep writing such a stuff 🙂
” What happens if reading fails? Is partial reading of the file sufficient for you? Can you nagivate the file? Should you close resources or they are automatically closed? ”
That’s what errors (or error codes) are supposed to tell you.
Even on C++ is simpler to read a single damn file than in Java. All that verbosiness is useless.
It doesn’t force you to understand nothing, just to remind all the lines or to make a macro/snipper/whatever you named to make it work for you, fast and simple.
Hi,
That’s interresting, and sure the java API with its verbosity force you to learn lot of things.
You could say that from nearly every language and technology. You always learn something. I really enjoyed my assembly course for example despite many where thinking it to be too low level. And even if I’am now a java dev for a living, studying clojure in my freetime, it is still usefull.
Now the question is should I take care of dealing with the stack content at each function call like you have to do in assembler code if all I want is to make a web application?
Low level API are good, but theses java API are not just low level, they are used everywhere and increase the verbosity of most java programs.
The standard pushed by Oracle is JEE with JSF, JMS and EJB. Not guava or apache commons.
The cost of that verbosity among all java user is in the billons dollars figures accumulated over the years.
cool, then it should be taught at universities alongside something not-o-so-verbose and the something ‘better’ should be used more. I’ll give you just a few simple examples that irritate me almost every day:
String str = new String() -> why???? isn’t ‘str = new String()’ or ‘var str = new String()’ if you need a keyword first. just simpler and as clear as java. even better, drop ‘new’ and do it like python. gets even cooler with generics 😉
the string manipulations… the horror, the horror. 3rd party libs help a bit but still gets me depressed. Same with collections 🙁
you’ve already mentioned the closures but the lack of treating a method as an object that can be easily pass around and used just generates more useless interfaces and then classes, anonymous or not depending if you prefer to get a headache from 3 billion files or a line starting at column 20+
there are many little things like that, both in API and syntax, that make java seems verbose to me. every time i come back after a week on not seeing java code but for example python i feel the the cart at my sweatshop is suddenly getting heavier for some unknown reason…
@catty, if you ask why “String” is needed in “String s = new String();” you probably never used a statically typed language (Java, C++, C). You may be used to dynamic typing (PHP, Python, etc) but complaining about static typing just shows your own ignorance.
@catty
Where is the supposed verbosity in EJB and JSF?
In e.g. EJB I typically only put a *single* annotation on a bean and it’s an EJB and fully transactional among others. Can you please explain where the verbosity is there? Please show an example, I’m really curious!
P.s.
Sorry, above posting is @Nicolas
@Flavio: sorry mate but this has nothing to do with dynamically typed thingy. the compiler/whatever has all it needs to resolve the type when you write x = String(). the example with ‘var’ is from C# 3.5 which is statically typed, also check out scala. btw i’m proud of my ignorance, couldn’t quite live without it
@Henk thanks for defending my point.
@catty – yes, this type inference within the same method is just some syntactic sugar that may be often confusing. It bothers you to write “String” instead of “var”? That’s some mechanical reduction of symbols that makes the code a bit harder to read. var foo = getFoo(); What is foo? You have to go and check the return type.
I also like the verbosity of Java first because the code is simpler to understand and second because it gives you more control.
I prefer seeing an algorithm in one page than in one line, it’s much easier to understand, modify and debug.
In fact I hate those examples that do way to many things in just one or two lines of code in other languages.
If you are one or just a few smart and experienced programmers working on something relatively simple then languages that offer “compressed code” are good, but for large applications with many programmers with different levels of knowledge a simpler more verbose language is much better.
I agree too. It’s like talking in real life to someone. There’s “ya can do da ding?” or there’s “Could you please go ahead and clean the kitchen?”.
Dynamic languages are like the former.
Great for a short script when the context is understood since it’s so small.
Static/strongly types languages are like the latter. Great for larger systems where you can’t even begin to have the entire context in your head and the code must be clear in isolation.
I love Static Typing, Java verbosity is good but sometimes I wish I could have type inference. For local scope variables type inference is the way to go as C#:
public void sayHello() { var myString = “Hello World”; System.Console.WriteLine(myString); }
As you see I dont need to go around to check what is the type because I know is just local to that method is there we can see it but I typed less. But also not go so far as Dynamic languages that is a mess to find the types or when come from that spaghetti.
Java needs:
1.Type inference
2.Closures
3.More easy way for parallelism
4.Jigsaw looks promising for java modularity
All this should be resolved by Java 8 or Scala.
The big trouble I see with Java is that, since it takes several steps to open a file, people consistently use the wrong steps.
At least 2/3 of the time that a junior programmer implements something in Java, they don’t use the correct character encoding. Everything looks like it works, until days, weeks, or months later you find data is corrupted because Unicode characters have scrambled.
Oddly, people are much more likely to write correct Unicode programs in a language like PHP which NEVER CORRUPTS DATA rather than Java which CORRUPTS DATA BY DEFAULT.
Java corrupts data? What are you smoking
Sorry for disagree but I don’t like the verbosity of Java at all, but I think that is a personal taste after all. As a C++ programmer too I would run away from C++ just to increase my productivity. I rarely have any memory management problem so if Java is just as verbose as C++ then I don’t see a real incentive to code in Java other than client’s requirements.
It’s true that verbosity allows you to pick hidden concepts on most high level programming languages but then why would you have that overhead when you have those concepts clear?
Its hard to believe that ‘verbosity’ is a real issue for people. What about design and reusability? I write a -lot- of Javascript as well as Python, Groovy and of course plenty of Java. Of all those languages, I prefer Java because it is allows our team to produce maintainable, readable code. When we write a large app in Javascript, it starts looking like Java (and if you take a look at many popular JS frameworks, you will notice the same). It seems like optional typing is the way people solve the ‘verbosity’ issue- take a look at Dart, for example.
@Miloskov java corrupts files by default because when you do new XxxReader the encoding parameter is optional.
@Paul Houle That said, php also corrupts data by default because it does not support UTF-8.
I think I agree with the post as soon as the syntaxic sugar of Eclise xtend is implemented natively in java (http://www.eclipse.org/Xtext/xtend/)
The most important IMHO :
* Closures
* Extension methods
* Type inference in the local scope
* Better switch (string notably, the switch case on the class is useless)
Not as important :
* operator overloading
* DSL
Should avoid :
* multiple dispatch (this is not backward compatible and may cause more harm than good)
Also, we really need a real modules paradigm in java so that I can avoid all these deprecated methods, the date / calendar implementation (give me LocalDate as Joda please !), and all that stuff that is kept for BC
As someone who started with Ruby/Python and is now learning Java, I have to disagree. It is certainly true that programming in Java forces you to learn more deeply how the low level mechanics of your program are working. But for that matter, so does programming in LISP, or for that matter, Assembly.
When you’re actually producing software for use in a commercial environment, the thing that matters most is “suitability for the task”, i.e. giving you exactly the power you need to accomplish your goal while consuming the least amount of resources. From this perspective, the mandatory verbosity of Java is expensive. It takes more time to code (and leads to more keystroke, worsening the risk of RSI which is a real threat to any programmer), and it’s naturally more error-prone leading to more time tracking down missing semi-colons or type errors that Ruby would sail past.
I’m a strong believer in Einstein’s “things should be as simple as possible, and not one bit simpler” dictum; sometimes you do need the customization power that verbosity affords. But much of the time, default behavior would suffice perfectly well. What would really be nice to see would be optional verbosity (along the lines of Rails) — verbosity / customization when you need it, convention when convention will suffice.
I agree w/ http://techblog.bozho.net/?p=742#comment-11134 . In C++ you can learn the low level stuff, then abstract them away (like a HLL is supposed to do). Also it looks nicer/is easier to read. Take operator overloading for example. We all know (s/all/most of us) know how .equals() works; now can we please just use `someObj == otherObj`? Java simply refuses to add new syntax, I’m not sure why; probably something to do with entry level programmers.
Have to agree with bawb here.
The reasons you give for liking verbosity might apply to people learning the language/framework. It doesn’t apply to people trying to make a living using it.
That’s akin to deliberately trying to drive screws with a hammer, because it lets you appreciate the way screws work.
I’m glad I “sparked” a discussion. I’m far from the idea that Java is the perfect language, and I deliberately used a subjective title – I like that particular thing. Whether it’s good in the long run or not – it has been for me, it’s certainly been bad for others.
As for C and Assembly – I wrote “slightly lower level”. The idea is that you won’t need memory management for your general-purpose Java CRM, but you will certainly need some advanced I/O. That, of course, differs depending on the project.
But overall, the verbosity is not something that should drive you away from the language/platform.
Watch this ->
Greg Wilson mentions that there a reliable studies which makes the point that on average, a programmer writes the same number of lines of code regardless of the language used. So a less verbose language with more expressive power can make a lot of difference. And as for the low/high level debate: “A programming language is low level when its programs require attention to the irrelevant. –Alan Perlis”
Actually I just don’t understand, why there aren’t conveniance functions within the Standard Libraries. Yes, you need the low jevel APIs, but in most cases it would be more useful to have the simplifications of Apache Commons or Guava etc. within the JDK.
The need for 3rdParty libs to solve standard use cases with Java is extremely high. Unfortunately junior level or even advanced developers don’t know all the frameworks they should have been using. Ans therefore they use the rudimentary, powerful, difficult low level JDK methods. And so the make errors. And you need “consultants” or “architects” to guide them through the framework jungle.
Sorry, but these are things that were solved better in Python et.al. I have to say that affter working in large team environments with Java for 12 years now.
+1 to that last comment. You become more of a ‘code plumber’ than anything when you work with Java for too long. Also, memory mgmt in c++ isn’t difficult with the proper use of destructors, then scope takes care of the rest. I’d recommend trying c++. There seems to be a lot of syntax at first, but this leads to much less code once you learn to use it. If you don’t want to try it, why not take a look at operator overloading? (here: http://www.cplusplus.com/doc/tutorial/classes2/ ). In the example they ‘add’ vector classes, which is (imo) easier to read than the equivalent that uses v1.add(v2)
Nicely put! +1 for mentioning “apart from anonymous classes-insteadof-closures” though. I’m really looking forward to Java 8!
Verbosity is bad in natural and programming languages. For an example try to read “Kritik der reinen Vernunft” by Kant in German. It’s long verbose language makes it nearly impossible to comprehend. A lot of (German) philosophy professors advice their students to read the English translation as it uses a less verbose language. 🙂
I find your commentary interesting and informative in most of your articles, but I disagree strongly on this issue. The problem with one liner libraries is *precisely* that newbies won’t understand them, and there will be a lot of duplication of effort, because they aren’t part of the programming language.
Verbosity is not a good thing in programming languages, because it increases the maintenance burden, and makes it harder for programmers to reason about programs in a modular way.
Functional programming languages largely handle this issue much better, such as Erlang. It encourages a relatively uniform use of concise idioms, while not supporting the ones most likely to intimidate novices (such as currying). Even though it is not by default a statically typed language, I use its type system in all my programs, and they are still very short.
I’d say if ML dialects (such as Standard ML, F#, Ocaml, Ur/Web, etc) were mainstream, people would see the true benefits of having concise code, although those are bit harder to learn than Erlang (but well worth the learning curve).
What’s up mates, how is everything, and what you desire to say on the topic of this post, in my view its really remarkable in support of me.
Right here is the right blog for everyone who wishes to find out about this topic.
You understand a whole lot its almost hard to argue with you (not that I personally
would want to…HaHa). You certainly put a brand new spin on a topic which has been written about for a long
time. Wonderful stuff, just excellent!
My spouse and I stumbled over here from a different web address and thought I may as well check things
out. I like what I see so now i am following you.
Look forward to finding out about your web page repeatedly.
The best tip when removing linoleum is to work in small sections.
The fresh colors will add a punch to your home’s d.
All of these items can be purchased at great prices at Oklahoma
City discount stores.
Hi there colleagues, how is all, and what you desire
to say on the topic of this article, in my view
its in fact amazing in support of me.
Hi, I reɑԁ yοur new stuff daily. Ύour story-telling style іѕ awesome,
ҡeep up the good work!
Τake a loօk at my blog – R3flection (r3flectioncream.net)
Came across this during a random Google search and wanted to point out that you and people that think like you are making the world a horrible place to live in.
% python3
>>> with open(‘output_file.dat’, ‘w’) as fha:
… fha.write(‘beautiful is better than ugly\n’)
…
Regards
Did you actually read the post? There are enough libraries that give you these one-liners, and they are widely used. Nobody writes a 10-line file-reading. But everyone knows all the underlying details, because when learning the base libraries, he had to understand it.
Java verbosity is not forcing you to learn important concepts, it forces you to learn the name of a bunch of classes. And then someone else comes with an IDE so that you don’t have to learn them anymore.
Code is (hopefully) written once and read hundreds of times. Verbosity wastes coders’ time always.
“There are enough libraries that give you these one-liners”
1. Yes, because all the underlying abstractions are horrible and really make no sense to be exposed.
2. “enough libraries” implies “more than one”, think about this: why?
“Nobody writes a 10-line file-reading”
Not only that, I see people prematurely optimizing the size of the buffer in their BufferedWriter _all_ the time.
“But everyone knows all the underlying details”
No, as you pointed out sane developers will use the one-liner implementation. Fools won’t.
Honestly, if you want to write files the “right way” you’d have to forget completely about using the JVM which calls the OS which calls a driver which chooses which surface and sector to write to and do it all yourself.
Otherwise default is best.
A really weak argument. If you want to learn about how things words under the hood, you open the source code and read it. You don’t force millions of developers to write repetitive, copy-paste code. There is no way that Java’s verbosity is justified. At least not in this article.
And then nobody will actually open the code and read it. If you have repetitive code rather than reusing commons libraries, it’s not Java’s problem