Why I like Java(blog.plover.com)
blog.plover.com
Why I like Java
http://blog.plover.com/prog/Java.html
425 comments
> So yes, I enjoyed programming in Java, and being relieved of the responsibility for producing a quality product.
Wow. What a pompous thing to say.
How does this have 91 points and is on the front page of HN?
Per the "most horrible answers were in Java", personally, I think he's missing selection bias, in that many newbie programmers who wouldn't know what they were doing in any language, think they "know" Java because they took a class on it.
I have no problem reading critiques of Java, not concise/etc., and like Scala/etc. as much as the next guy, but "relieved of the responsibility for producing a quality product"? Wow.
I suppose I'll add the disclaimer that if his 3 years of putting in time writing Java were doing J2EE, then I'll understand where he's coming from. But that's not the language.
Wow. What a pompous thing to say.
How does this have 91 points and is on the front page of HN?
Per the "most horrible answers were in Java", personally, I think he's missing selection bias, in that many newbie programmers who wouldn't know what they were doing in any language, think they "know" Java because they took a class on it.
I have no problem reading critiques of Java, not concise/etc., and like Scala/etc. as much as the next guy, but "relieved of the responsibility for producing a quality product"? Wow.
I suppose I'll add the disclaimer that if his 3 years of putting in time writing Java were doing J2EE, then I'll understand where he's coming from. But that's not the language.
So I was a Java developer from 2006-2012. I still occasionally touch Java at work.
Off the top of my head, right now, in this text box, without google, I can't write the code to copy standard input to standard output.
System.out.println(System.in)? That's wrong. You need some kind of InputReader, or BufferedInputReader, or Buffered...something. I think System.in is an InputStream, so presumably I need to do new InputReader(System.in)? Or BufferedInputReader? Should I buffer the output?
Ok, let's do some API googling (ie, not StackOverflow).
So I was... pretty wrong. I think what you want is:
public class CopyInput { public static void main(String[] args) { while (true) System.out.write(System.in.read); } }
I haven't tried to run this though.
In my defence, I have never, in all my years of working, had to ever read standard input, let alone write it out again.
Off the top of my head, right now, in this text box, without google, I can't write the code to copy standard input to standard output.
System.out.println(System.in)? That's wrong. You need some kind of InputReader, or BufferedInputReader, or Buffered...something. I think System.in is an InputStream, so presumably I need to do new InputReader(System.in)? Or BufferedInputReader? Should I buffer the output?
Ok, let's do some API googling (ie, not StackOverflow).
So I was... pretty wrong. I think what you want is:
public class CopyInput { public static void main(String[] args) { while (true) System.out.write(System.in.read); } }
I haven't tried to run this though.
In my defence, I have never, in all my years of working, had to ever read standard input, let alone write it out again.
I don't know why so many cool programmers hate Java. Sure the library is too big and sometimes is hard to find the proper stream class. Or the Date class is antiquated.
Ignoring that, what I like about java is that my programs are clear, and that once I compile my programs, they just work. I can refactor my code, and the compiler makes sure that I don forget anything. I don't love it they way I loved Perl or C. But when I write Java, I feel confident that my program is not going to break; and even if it breaks a stack exception is going to point me directly to the offending line.
Of course you don't have to use 25 Design Patterns at the same time. But lets not blame Gosling for that, that is the fault of the "Enterprise Architects", I still think you can write good tight java code.
Ignoring that, what I like about java is that my programs are clear, and that once I compile my programs, they just work. I can refactor my code, and the compiler makes sure that I don forget anything. I don't love it they way I loved Perl or C. But when I write Java, I feel confident that my program is not going to break; and even if it breaks a stack exception is going to point me directly to the offending line.
Of course you don't have to use 25 Design Patterns at the same time. But lets not blame Gosling for that, that is the fault of the "Enterprise Architects", I still think you can write good tight java code.
"Look, he couldn't even copy stdin to stdout, LOLOL".
The most probable reason for the failure is because Java is not used in industry that much as a shell programming environment. The most common use case for Java is as a server-side, long-running server, with C++-like performance and without C++-like headaches. I work with algorithmic trading engines in my job. Though I trade personally these days and the orders are small, the engines I implemented for banks typically handle $250m worth orders per stock exchange. I have NEVER, not in a single instance in the last 5 years, have had to read from stdin in Java. Why : in my particular niche in my industry, input comes via a socket that is abstracted away by an engine that implements the FIX (Financial Information eXchange) protocol. For all practical purposes, in the finance industry, the FIX library / server IS stdin and stdout. This doesn't make a colleague of mine who forgot how to access stdin in Java a nincompoop. It's a failure to remember what is rarely used, not a failure to perform basic job duties. See the difference?
I believe the author is / was a Perl expert? That's why he thinks being able to read stdin is "so basic". I challenge the author to confront his prejudices : hire a few candidates who fail the stdin / stdout test. If they are allowed to do the damn work instead of jumping through your Perl-shaped hoops, they might have actually done quite well on the job.
Similarly, many Perl programmers would fail a test devised by someone who is used to Java.
The most probable reason for the failure is because Java is not used in industry that much as a shell programming environment. The most common use case for Java is as a server-side, long-running server, with C++-like performance and without C++-like headaches. I work with algorithmic trading engines in my job. Though I trade personally these days and the orders are small, the engines I implemented for banks typically handle $250m worth orders per stock exchange. I have NEVER, not in a single instance in the last 5 years, have had to read from stdin in Java. Why : in my particular niche in my industry, input comes via a socket that is abstracted away by an engine that implements the FIX (Financial Information eXchange) protocol. For all practical purposes, in the finance industry, the FIX library / server IS stdin and stdout. This doesn't make a colleague of mine who forgot how to access stdin in Java a nincompoop. It's a failure to remember what is rarely used, not a failure to perform basic job duties. See the difference?
I believe the author is / was a Perl expert? That's why he thinks being able to read stdin is "so basic". I challenge the author to confront his prejudices : hire a few candidates who fail the stdin / stdout test. If they are allowed to do the damn work instead of jumping through your Perl-shaped hoops, they might have actually done quite well on the job.
Similarly, many Perl programmers would fail a test devised by someone who is used to Java.
JVM is the best like the Swiss Army of creating good superficial impression.
Want to show off to the web CRUD hipsters, you can go Groovy, Grails and Play framework.
Want to show off to the Enterprise architect astronauts, you can go Hibernate, Spring, ElasticSearch and JBoss.
Want to show off to the Big Data ivory tower academics, you can go Weka, Lucene, Hadoop and Scala.
Want to show off to the esoteric language hipsters, you can go Clojure, JRuby, Jython, JScheme and Rhino.
Sun Microsystems and applets on IE6 live on in my big heart warmed up by hot cup of cappuccino beans.
Want to show off to the web CRUD hipsters, you can go Groovy, Grails and Play framework.
Want to show off to the Enterprise architect astronauts, you can go Hibernate, Spring, ElasticSearch and JBoss.
Want to show off to the Big Data ivory tower academics, you can go Weka, Lucene, Hadoop and Scala.
Want to show off to the esoteric language hipsters, you can go Clojure, JRuby, Jython, JScheme and Rhino.
Sun Microsystems and applets on IE6 live on in my big heart warmed up by hot cup of cappuccino beans.
Never understood the hate towards Java on HN. Java is not perfect by any means but every one of the other languages he mentions in that article (Perl, Python, Ruby, JavaScript) also has their shortcomings. People focus way too much on technology and not enough on the results.
It reminds me of a great post by Coda Hale a couple of years back where he was explaining why he switched back to Java from Scala (which was hot shit on HN at the time):
http://codahale.com/the-rest-of-the-story/
"The world has yet to take me aside and ask me for my opinion of it, and in the past few years I’ve found that it’s far more profitable to build things rather than tilt at windmills."
It reminds me of a great post by Coda Hale a couple of years back where he was explaining why he switched back to Java from Scala (which was hot shit on HN at the time):
http://codahale.com/the-rest-of-the-story/
"The world has yet to take me aside and ask me for my opinion of it, and in the past few years I’ve found that it’s far more profitable to build things rather than tilt at windmills."
A language is a tool.
Some people obsess over the tool itself. My tool has these 10 features, and it was hand crafted and it can solve 8 Queen problem in 2 lines and it has monads or a cute puppy for a mascot and so on. People who use tools obsess about them, and it kind of becomes the end not just a means to an end. They would read about the new features in the language, they would run over tutorials in their free time and so on. There is a good amount of pleasure derived from fawning over the tool itself.
Others don't care about the language or the framework, they just want to job to be done and get paid. It turns out that some part of code they are working on is written in FORTRAN, COBOL, or (oh the horror!) MUMPS, that won't bother them much. They'll just figure it out and fix the issue. The pleasure comes from getting paid and solving the business problem at hand.
Both are extremes and there is a continuum between the two on which most people fall. Neither extreme I think is healthy and at the same time there are good parts about each one --
Someone who cares about the tools they are using will probably also use the tool better and more effectively. Someone who is picky about the type of hammers and their design and knows the history is also probably pretty good at hammering nails in. They might spend $1000 for a titanium hammer but hey they will be good at it.
Also someone who cares to get the job done and derives pleasure from solving a business problem, might just be the one keeping the product/company/startup afloat. Making money and delivering products is the top goal of most companies. This often means what seem to be boring, old, broken, unfashionable frameworks or tools. But so what, look we are still getting a paycheck!
There is a validity in both.
Some people obsess over the tool itself. My tool has these 10 features, and it was hand crafted and it can solve 8 Queen problem in 2 lines and it has monads or a cute puppy for a mascot and so on. People who use tools obsess about them, and it kind of becomes the end not just a means to an end. They would read about the new features in the language, they would run over tutorials in their free time and so on. There is a good amount of pleasure derived from fawning over the tool itself.
Others don't care about the language or the framework, they just want to job to be done and get paid. It turns out that some part of code they are working on is written in FORTRAN, COBOL, or (oh the horror!) MUMPS, that won't bother them much. They'll just figure it out and fix the issue. The pleasure comes from getting paid and solving the business problem at hand.
Both are extremes and there is a continuum between the two on which most people fall. Neither extreme I think is healthy and at the same time there are good parts about each one --
Someone who cares about the tools they are using will probably also use the tool better and more effectively. Someone who is picky about the type of hammers and their design and knows the history is also probably pretty good at hammering nails in. They might spend $1000 for a titanium hammer but hey they will be good at it.
Also someone who cares to get the job done and derives pleasure from solving a business problem, might just be the one keeping the product/company/startup afloat. Making money and delivering products is the top goal of most companies. This often means what seem to be boring, old, broken, unfashionable frameworks or tools. But so what, look we are still getting a paycheck!
There is a validity in both.
> In Java, you can forget about doing it in the cleanest or the best way, because that is impossible. Whatever you do, however hard you try, the code will come out mediocre, verbose, redundant, and bloated
(reason for liking Java)
Well, here are some other reason for liking Java: https://medium.com/i-m-h-o/da3b2c180e9c
But I really believe the future of software is affected more by having better programmers rather than having better languages.
Yes, it helps to have cool languages like Julia, Nimrod, Rust, even Scala (which I think is the best statically typed JVM language out there). But I tend to think that a good developer will be good in any language, Haskell, C, Java or LOLCODE.
I think that a good developer "forced" to use Java will find tools that bring out the good parts of the language: Dropwizard, Play framework / Akka, even latest versions of Spring and Java EE are much more convention over configuration and lightweight than before. They will use Guava and Apache commons to streamline common Java verbosity and bloat. They'll use Java 8 which allows much more robust and concise syntax to common problems.
But I don't think that the language is the problem. I think that a great developer will be able to tackle any problem with the language itself easily, because the real problem is not how to implement X, but more what is X. Designing the software correctly is the main problem at hand, not how to move input to output. This is what stackoverflow is for.
One last point about this all "I hate/like Java" type of post
1) If you write Java for your day job and hate it, either try to introduce something else (Clojure / Scala / Java 8 / Kotlin) If you can't introduce any of these then either accept your fate or just quit and find another job. If you can't find another job, then perhaps you deserve to stay and write Java so stop whining, it's not that bad (and one day you'll get to use Java 8).
2) If you don't write java for your day job but as a freelancer - start getting other non-java gigs. Not so many non Java jobs? well, continue to write Java bashing blog posts until people will stop using it I guess...
3) If you don't write Java for your day job or as a freelancer, then just stop complaining about it. There are million of other things (not just programming languages) out there worth complaining about. They can use your writing talent for a better cause.
(reason for liking Java)
Well, here are some other reason for liking Java: https://medium.com/i-m-h-o/da3b2c180e9c
But I really believe the future of software is affected more by having better programmers rather than having better languages.
Yes, it helps to have cool languages like Julia, Nimrod, Rust, even Scala (which I think is the best statically typed JVM language out there). But I tend to think that a good developer will be good in any language, Haskell, C, Java or LOLCODE.
I think that a good developer "forced" to use Java will find tools that bring out the good parts of the language: Dropwizard, Play framework / Akka, even latest versions of Spring and Java EE are much more convention over configuration and lightweight than before. They will use Guava and Apache commons to streamline common Java verbosity and bloat. They'll use Java 8 which allows much more robust and concise syntax to common problems.
But I don't think that the language is the problem. I think that a great developer will be able to tackle any problem with the language itself easily, because the real problem is not how to implement X, but more what is X. Designing the software correctly is the main problem at hand, not how to move input to output. This is what stackoverflow is for.
One last point about this all "I hate/like Java" type of post
1) If you write Java for your day job and hate it, either try to introduce something else (Clojure / Scala / Java 8 / Kotlin) If you can't introduce any of these then either accept your fate or just quit and find another job. If you can't find another job, then perhaps you deserve to stay and write Java so stop whining, it's not that bad (and one day you'll get to use Java 8).
2) If you don't write java for your day job but as a freelancer - start getting other non-java gigs. Not so many non Java jobs? well, continue to write Java bashing blog posts until people will stop using it I guess...
3) If you don't write Java for your day job or as a freelancer, then just stop complaining about it. There are million of other things (not just programming languages) out there worth complaining about. They can use your writing talent for a better cause.
You may well be thinking, "Can it really be that hard to figure out how to open stdin?" Having just attempted it, I can confirm that it's hard. Shockingly hard. I could have easily failed that test.
I consider myself a fairly competent programmer, and I have a little knowledge of Java, including building GUIs and so on. Here's the Hello World program off the top of my head:
Bingo! I've found System.in, and it says it's an InputStream. So now I just need to find ... ah ... there are three of them. Is System.in a java.io.InputStream, org.omg.CORBA_2_3.portable.InputStream, or org.omg.CORBA.portable.InputStream? The documentation doesn't say.
Well, I have a vague idea of what CORBA is, and I don't think I'm using CORBA here, so it must be java.io. Good first problem solved. Now, what methods can I use?
I figured it out in the end, but only through pure luck: I need to wrap System.in in a java.io.InputStreamReader.
I consider myself a fairly competent programmer, and I have a little knowledge of Java, including building GUIs and so on. Here's the Hello World program off the top of my head:
public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello World.");
}
}
Bingo! I've found System.in, and it says it's an InputStream. So now I just need to find ... ah ... there are three of them. Is System.in a java.io.InputStream, org.omg.CORBA_2_3.portable.InputStream, or org.omg.CORBA.portable.InputStream? The documentation doesn't say.
Well, I have a vague idea of what CORBA is, and I don't think I'm using CORBA here, so it must be java.io. Good first problem solved. Now, what methods can I use?
abstract int System.in.read()
int System.in.read(byte [] b)
int System.in.read(byte [] b, int off, int len)
I figured it out in the end, but only through pure luck: I need to wrap System.in in a java.io.InputStreamReader.
I think the author takes it a bit too far: It's possible that the Java programmers have valuable skills that we could use, despite their inability to produce even a trivial working program in a short amount of time.
The fact that I/O management is cumbersome in Java doesn't relate to the ability of Java programmers to provide value.
The fact that I/O management is cumbersome in Java doesn't relate to the ability of Java programmers to provide value.
If you're writing mediocre code and are happy with it, the problem might not lie with the language.
> I was a professional Java programmer for three years
3 years is about the amount of time it took me to get a false sense of security in my understanding of a language, imo. After 3 years i thought I knew Java. After 3 years I thought I knew Ruby. I was wrong.
BTW- if I were to receive a question on my application asking how to read stdin and write stdout, that would be a bad sign.
> So yes, I enjoyed programming in Java, and being relieved of the responsibility for producing a quality product.
Many quality products I use have been written in Java.
> It was pleasant to not have to worry about whether I was doing a good job, or whether I might be writing something hard to understand or to maintain.
Though, I understand the intended meaning of "Java is too verbose", You can write code in Java that is easier to maintain. Java is not an excuse for poorly written code.
> The code was ridiculously verbose, of course, but that was not my fault. It was all out of my hands.
You get paid to write maintainable code that does what is intended. It was never "out of your hands".
I no longer like Java as much, but I don't think Java ever was a reason to sit back and let bad code happen.
3 years is about the amount of time it took me to get a false sense of security in my understanding of a language, imo. After 3 years i thought I knew Java. After 3 years I thought I knew Ruby. I was wrong.
BTW- if I were to receive a question on my application asking how to read stdin and write stdout, that would be a bad sign.
> So yes, I enjoyed programming in Java, and being relieved of the responsibility for producing a quality product.
Many quality products I use have been written in Java.
> It was pleasant to not have to worry about whether I was doing a good job, or whether I might be writing something hard to understand or to maintain.
Though, I understand the intended meaning of "Java is too verbose", You can write code in Java that is easier to maintain. Java is not an excuse for poorly written code.
> The code was ridiculously verbose, of course, but that was not my fault. It was all out of my hands.
You get paid to write maintainable code that does what is intended. It was never "out of your hands".
I no longer like Java as much, but I don't think Java ever was a reason to sit back and let bad code happen.
Java is a likable language. It's not a lovable language.
It occupies a weird middle ground where you give up the capability to code to bare metal or easily interface with C functions in exchange for nearly being able to quickly and succinctly create powerful abstractions.
There's not a whole lot wrong with it, but I don't think I've ever been using any other language and missed something from Java. But when using Java that experience is common and I find the amount of effort you have to put in to not write repetitive code is annoying and results in overly complex architectures.
It occupies a weird middle ground where you give up the capability to code to bare metal or easily interface with C functions in exchange for nearly being able to quickly and succinctly create powerful abstractions.
There's not a whole lot wrong with it, but I don't think I've ever been using any other language and missed something from Java. But when using Java that experience is common and I find the amount of effort you have to put in to not write repetitive code is annoying and results in overly complex architectures.
Another story to go with the author's story about people who fail a code test because of Java:
At MIT, in 2003, there was a class called 6.171 Software Engineering for Web Applications. The final project was, in fact, to design and make a web application. It was very open-ended and it could be in any language you wanted.
This particular course soon stopped being taught, because a large number of people failed the final project. They could not make an application that functioned in any way by the time the course was over. (Keep in mind: 2003. There weren't really any easy answers to web applications.)
Many people had chosen to do their project in Java, because that's what they had learned and used in the prerequisite course. And in particular, over half of the people who chose Java failed.
(By the way, the course on web applications is now the main project-based course on software engineering at MIT, and it is now taught in Ruby.)
At MIT, in 2003, there was a class called 6.171 Software Engineering for Web Applications. The final project was, in fact, to design and make a web application. It was very open-ended and it could be in any language you wanted.
This particular course soon stopped being taught, because a large number of people failed the final project. They could not make an application that functioned in any way by the time the course was over. (Keep in mind: 2003. There weren't really any easy answers to web applications.)
Many people had chosen to do their project in Java, because that's what they had learned and used in the prerequisite course. And in particular, over half of the people who chose Java failed.
(By the way, the course on web applications is now the main project-based course on software engineering at MIT, and it is now taught in Ruby.)
If I interviewed for a company where a serious interview question was to copy stdin to stdout I'd probably laugh and walk out. Stating the obvious: this company obsesses over the most efficient way to re-invent the wheel... Good luck getting any real work done or learning any career portable skills!
A corollary: we use Java and Python mostly, and when interviewing candidates, the vast majority of them choose to give their answers in Java. I don't ask particularly hard questions, but I find that I usually get a good sense of the candidate by just talking to him as he's working out the answer.
This one guy chose Python, which delighted me since it's so rare. He then proceeded to produce answers much more easily than the average candidate, and he was able to make changes as I suggested them without too much effort.
We hired him but had to let him go after a month, when it became clear that he wasn't as good as I'd thought he was. Turns out it was Python that just made him look smart.
I like Java for actually getting things done, but it's such a vast ocean of TMTOWTDI that interviewing in it seems harder than in smaller languages.
This one guy chose Python, which delighted me since it's so rare. He then proceeded to produce answers much more easily than the average candidate, and he was able to make changes as I suggested them without too much effort.
We hired him but had to let him go after a month, when it became clear that he wasn't as good as I'd thought he was. Turns out it was Python that just made him look smart.
I like Java for actually getting things done, but it's such a vast ocean of TMTOWTDI that interviewing in it seems harder than in smaller languages.
"I am reminded of Dijkstra's remark that the teaching of BASIC should be rated as a criminal offense. Seeing the hapless candidate get bowled over by a question that should be a mere formality makes me wonder if the same might be said of Java."
Well, actually it has been said by Dijkstra again. www.cs.utexas.edu/users/EWD/OtherDocs/To%20the%20Budget%20Council%20concerning%20Haskell.pdf
Well, actually it has been said by Dijkstra again. www.cs.utexas.edu/users/EWD/OtherDocs/To%20the%20Budget%20Council%20concerning%20Haskell.pdf
Hum. If that's a positive spin on Java, you can count me unimpressed.
I have a side project I'm maintaining (all in) Java that I spent a weekend on about two months ago. Frankly, it was ridiculously easy to splat out code with Eclipse (and not get anything done, but that's mostly my fault).
Several fundamental issues showed up:
- lack of first-class functions
- lack of extensibility on extant classes
- grossly mutating state
- Loads and loads of code that obscured what the logic of the program was
Project Lombok is a heinous hack to try to get around these issues (somewhat). So is, afaict, AOP.
I think for the right project - and with ruthlessly non-generic design - Java is the right tool. Otherwise you wind up with reams of wasted paper and mental overhead grappling with the sheaf of low-entropy code you've got.
I have a side project I'm maintaining (all in) Java that I spent a weekend on about two months ago. Frankly, it was ridiculously easy to splat out code with Eclipse (and not get anything done, but that's mostly my fault).
Several fundamental issues showed up:
- lack of first-class functions
- lack of extensibility on extant classes
- grossly mutating state
- Loads and loads of code that obscured what the logic of the program was
Project Lombok is a heinous hack to try to get around these issues (somewhat). So is, afaict, AOP.
I think for the right project - and with ruthlessly non-generic design - Java is the right tool. Otherwise you wind up with reams of wasted paper and mental overhead grappling with the sheaf of low-entropy code you've got.
I used to feel Java was a pain to write when working with Java 6. Many 250 characters lines and everything.
Java 7 kinda divided the line length by a factor 2 with the diamond operator, the try-resource and so on.
I've programmed some Java 8 since yesterday and it actually feels like a pretty decent language to express ideas. Nothing like Java 6.
I know most of the Java haters have been struggling using it day to day in settings were it was awful (over engineering + Java 6, hello, here is the gun).
But I feel like those haters should really try to think fresh on this one. Try Java 8 and its new features and decide for yourself _afterwards_.
Java 7 kinda divided the line length by a factor 2 with the diamond operator, the try-resource and so on.
I've programmed some Java 8 since yesterday and it actually feels like a pretty decent language to express ideas. Nothing like Java 6.
I know most of the Java haters have been struggling using it day to day in settings were it was awful (over engineering + Java 6, hello, here is the gun).
But I feel like those haters should really try to think fresh on this one. Try Java 8 and its new features and decide for yourself _afterwards_.
Is this what he's looking for?
public static void main(String[] args) throws IOException {
int ch;
while ((ch = System.in.read()) != -1)
System.out.print((char) ch);
}The JVM is an awesome piece of tech - it still boggles my mind that runtime performance can get <2x native C speed for many applications.
Java itself less so. It is just far too verbose. I found that I would get completely frustrated coding in an editor without code generation. Using Netbeans to generate most of the boilerplate code was the only way I stayed sane coding in Java. I cannot imagine having to write lots of production Java code in a "normal" editor. If my IDE can figure out what I'm trying to do, so should my programming language.
Java itself less so. It is just far too verbose. I found that I would get completely frustrated coding in an editor without code generation. Using Netbeans to generate most of the boilerplate code was the only way I stayed sane coding in Java. I cannot imagine having to write lots of production Java code in a "normal" editor. If my IDE can figure out what I'm trying to do, so should my programming language.
Interesting polemic. The arguments aren't super compelling to me.
Ultimately java is just a tool. The culture around it shapes the macro picture but still.
Ultimately java is just a tool. The culture around it shapes the macro picture but still.
"Whatever you do, however hard you try, the code will come out mediocre, verbose, redundant, and bloated"
That's, unfortunately, common misconception and excuse for writing bad software in Java.
Java has its own problems (as if other languages does not have them), rigid objects creation that has to be overcome by dependency injection, nulls that has to be overcome by using Optionals, badly designed time/date handling standard libraries, etc.
However there is a huge number of good quality, well design libraries that make Java shine.
- Guava gives us functional-like programming style plus nice collection handling - Joda Time solves problems with date/time handling - Lombok (projectlombok.org) cleans up code from getters/setters clutter - Need a nice, collections only library, there is plenty of them (for instance GS Collections) - You need to create super performant server? Just use Vert.x, Distruptor library, you are getting nice APIs and a lot of functionality for nothing - You want to write nice, concurrent code without using low level primitives, no problem, go with Akka - You need to orchestrate actions flow in your (huge) application - do it easyly, elegantly and almost without coding using Apache Camel - Google Guice dependency injection library provides nice workaround for a rigid object creation strategy in Java
And so on, and so on. Java ecosystem is changing, there are new ideas that refresh language, despite its rigidness (no macros).
That's, unfortunately, common misconception and excuse for writing bad software in Java.
Java has its own problems (as if other languages does not have them), rigid objects creation that has to be overcome by dependency injection, nulls that has to be overcome by using Optionals, badly designed time/date handling standard libraries, etc.
However there is a huge number of good quality, well design libraries that make Java shine.
- Guava gives us functional-like programming style plus nice collection handling - Joda Time solves problems with date/time handling - Lombok (projectlombok.org) cleans up code from getters/setters clutter - Need a nice, collections only library, there is plenty of them (for instance GS Collections) - You need to create super performant server? Just use Vert.x, Distruptor library, you are getting nice APIs and a lot of functionality for nothing - You want to write nice, concurrent code without using low level primitives, no problem, go with Akka - You need to orchestrate actions flow in your (huge) application - do it easyly, elegantly and almost without coding using Apache Camel - Google Guice dependency injection library provides nice workaround for a rigid object creation strategy in Java
And so on, and so on. Java ecosystem is changing, there are new ideas that refresh language, despite its rigidness (no macros).
Use Java when you're paid by the hour.
Use Clojure when you're paid by the project.
Use Haskell when you need to ensure job security.
Use Clojure when you're paid by the project.
Use Haskell when you need to ensure job security.
TL;DR
"There are many bad java programmers, hence java is bad. Even I was bad at it. Saying that I like java is just sarcastic link bait."
"There are many bad java programmers, hence java is bad. Even I was bad at it. Saying that I like java is just sarcastic link bait."
He doesn't like java.
I've been programming in java for years and I still cannot make a program that compiles on the first try, unless I 'cheat' using an IDE or peeking at the API.
I couldn't even do the 'read-from-input write-to-output' thing mentioned in the example.
It's true it's because of the language: I've believe Java is more 'Enterprise' and sophisticated.
But I KNOW that because of this I tend to write better code (at least more standardized and better structured) in Java than in other languages I've had the same practice with, such as C, C++ or PHP, even though I don't need any IDE or manual of any kind to write such a simple program on those. And, no matter the language, it takes me the same time to do it right.
My conclusion is: If you like to 'hack together' a tool Java is probably not the best choice of language; If you want to build some big project on a team and keep it robust and maintainable using efficient libraries, it is.
I couldn't even do the 'read-from-input write-to-output' thing mentioned in the example.
It's true it's because of the language: I've believe Java is more 'Enterprise' and sophisticated.
But I KNOW that because of this I tend to write better code (at least more standardized and better structured) in Java than in other languages I've had the same practice with, such as C, C++ or PHP, even though I don't need any IDE or manual of any kind to write such a simple program on those. And, no matter the language, it takes me the same time to do it right.
My conclusion is: If you like to 'hack together' a tool Java is probably not the best choice of language; If you want to build some big project on a team and keep it robust and maintainable using efficient libraries, it is.
What I liked about Java is:
* The IDE
* Staticness and strictness
* The JEE deployment model. I think this is overlooked and unappreciated. Having a standard way to specify database connections, queues, etc is very nice. I had never stored any passwords in the source repository
I'm a professional Java dev and couldn't do this from the top of my head without System.* documentation.
But if I can choose the language it's easy...
But if I can choose the language it's easy...
#!/bin/bash
cat
But it's not making a good point. It's not even close. I wish people would stop voting it up.
- "In Java, you can forget about doing it in the cleanest or the best way, because that is impossible." -- cleanest in any language? Or cleanest for Java? Of course the "cleanest" way for Java is possible, and it does matter -- there is a huge difference between "clean" Java and unclean, and anyone who says otherwise is a Java pretender. And arguing about "cleanest for any language" is just a proxy for a language flamewar.
- "And nobody can glare at you and demand to know why you used 576 classes when you should have used 50, because in Java doing it with only 50 classes is probably impossible." -- The "Har-har-so-many-classes-and-don't-even-get-me-started-on-variable-names" argument. In Java, as in any language, you can over-design, or you can under-design, or you can design just what you need. The number of classes may end up higher than in other languages, but this argument is silly and tired, and yes, length is one of the tradeoffs of Java. An IDE (gasp!) should make that largely irrelevant.
- "The code was ridiculously verbose, of course, but that was not my fault. It was all out of my hands." -- This word "verbose" keeps being thrown around as an insult, but nobody brings up the tradeoffs. Verbosity has a purpose, just like brevity and terseness do. And of course it's never out of the programmers' hands. Once given a language, it's all relative.
There's more, but I'm arguing with a person who believes that a question about stdin and stdout is a proper gateway for measuring skill toward any programming problem ever.