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.
Recent Comments