
Why I like Java - snupples
http://blog.plover.com/prog/Java.html
======
chavesn
This is one of those criticisms that sounds right if you know a little bit
about the topic, and is certainly clever enough in and of itself to make the
reader think that it's making a good point.

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_.

~~~
rjknight
I took his post as a fairly standard "worse is better" argument. Many newer or
more fashionable languages enable some very _elegant_ programming styles, but
this comes with a concern about the elegance of one's code, which can easily
result in the programmer spending more time thinking about elegance than about
functionality. For example... should I use map or reduce here, or maybe an
iterator, or... oh fuck it, I'll use a for loop. It turns out that the old-
school for loop works just as well despite earning you precisely zero style
points.

There's actually something quite liberating about languages that deny you any
clever solutions. Just write code that works and don't worry about whether you
could have used <fashionable programming concept X> instead. I found Go to be
quite refreshing for the same reason - the standard library is pretty small
and the language lacks anything particularly magical, even some stuff that
Java has like generics. The end result, however, is code that is very easy to
read and write for anyone who learned imperative programming in the last 30
years.

~~~
Curmudgel
> Many newer or more fashionable languages enable some very elegant
> programming styles, but this comes with a concern about the elegance of
> one's code, which can easily result in the programmer spending more time
> thinking about elegance than about functionality.

That's a common anti-intellectual fallacy about why people code in higher
level languages. High level languages are attractive because they let you
write code faster and make your code easier to maintain, and not because
they're "fashionable".

>There's actually something quite liberating about languages that deny you any
clever solutions

To me, "deny[ing] clever solutions" translates to "this code is going to be a
pain in the ass to write because I'm going to waste time fighting the language
to get what I want." Programmers learn to avoid unnecessarily complicated code
as they gain more experience. Mature programmers should have the freedom to
exercise their judgement about what kind of code is appropriate.

~~~
macspoofing
>High level languages are attractive because they let you write code faster
and make your code easier to maintain, and not because they're "fashionable".

Maybe, maybe not. But at least 2 of the 3 points that you made are not true of
JavaScript. Also, the whole "write code faster" has always been perplexing to
me. The speed at which you write code is never significantly different between
any two mainstream languages to really matter in the end, especially since the
lifetime of a piece of software is dominated by maintenance.

And I don't know what you mean by "High level language". Java is a high level
language.

>To me, "deny[ing] clever solutions" translates to "this code is going to be a
pain in the ass to write because I'm going to waste time fighting the language
to get what I want."

There's clever and then there's too clever.

~~~
jerf
"Also, the whole "write code faster" has always been perplexing to me. The
speed at which you write code is never significantly different between any two
mainstream languages to really matter in the end, especially since the
lifetime of a piece of software is dominated by maintenance."

One of the very few bits of relatively solid software engineering that we have
is that line count for a given task _does_ matter. Fewer lines written by the
programmer to do the same thing strongly tends to yield higher productivity.
(Note the "by the programmer" clause; lines autogenerated... well...
_correctly_ autogenerated tend not to count against the programmer, which is
an important part of doing Java, or so I hear.)

And remember, if this were _not_ true, we'd be programming entirely
differently; why do anything but assembler if line count doesn't matter? You
might be tempted to thing that's some sort of rhetorical exaggeration, since
it sort of sounds like one, but it's not; it's a very serious point. If line
counts are actually _irrelevant_ , then we'd never be bothering with high-
level languages, which up until fairly recently have the primary purpose of
doing a whole bunch of things which, in the end, reduce line count.

(Slowly but surely we're starting to see the mainstream introduction and use
of languages that _also_ focus on helping you maintain invariants, but that
has still historically speaking been a sideline task and niche products.)

~~~
ssmoot
Do you have a citation for that?

Because I'd totally buy that the number of _expressions_ matters.

But I really doubt actual lines matters much.

~~~
jerf
In theory, I have a citation. There have been actual studies done that show
roughly equal productivity in several languages as measured by lines of those
languages. However, I can't google them up through all the noise of people
complaining about line counts being used for various things. And I phrased it
as "one of the very few bits of relatively solid software engineering" on
purpose... that phrase isn't really high praise. You can quibble all day about
the precise details, not least of which is the age of the studies in question.

Still, I do stick by my original point... if you think lines of code are
_irrelevent_ , it becomes very difficult to understand the current landscape
of language popularity. A language in which simply reading a line from a file
is a multi-dozen line travesty is harder to use than a language in which it's
two or three, and that extends on through the rest of the language. I know
when I go from a language where certain patterns are easy into a higher B&D
language where the right thing is a lot more work, I have to fight the urge to
not do the lot-more-work, and this higher level "how expensive is it to use
the _correct_ pattern?" is a far more important, if harder to describe,
consideration across non-trivial code bases.

~~~
ssmoot
I wasn't attacking your comment. Just curious about the citation since it
doesn't intuitively sit right with me I guess.

------
stephen
> 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.

~~~
pjmlp
> How does this have 91 points and is on the front page of HN?

Because HN is full of Java hate, where all cool guys would never touch the
JVM.

Meanwhile the world moves along and JVM based products get deployed every day.

~~~
suyash
Forget the 'cool guys', the best software engineers love Java.

~~~
bulte-rs
My internal me was screeeaming just to put "citation needed" here (I've never
done it before, this is not a good time to start). And while I agree with you
on a certain level; I don't think "Java engineers" are the best software
engineers per se. Neither that the best software engineers love Java 'without
exception'.

I agree [with you] that Java invites you (nay, urges you) to use good
engineering practices.

~~~
orkoden
But you love Java for its exceptions.

~~~
bulte-rs
It's sad I can't edit my message anymore. Thanks for lightening it up.

At least exceptions ensure (...) - at least in Java - that errors are forced
to be dealt with in a certain way.

bulte-rs - orkoden: 0 - 1; I love Java for it's exceptions (and "the IDE's"
telling me to catch them all).

------
SCdF
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.

~~~
bermanoid
I was about to say the exact same thing: I'd probably walk out of an interview
if remembering how to read stdin was part of it, because it comes up maybe
once every couple of years in real work, better to just Google it.

Don't tailor from-memory standard library questions to bits of code that
almost nobody ever has to use.

~~~
cbsmith
> Don't tailor from-memory standard library questions to bits of code that
> almost nobody ever has to use.

So seriously? You almost never need to read & write to streams?

~~~
bermanoid
No. I almost never need to read from stdin, as I said.

Again, most of us write real apps, not command line utilities.

------
huherto
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.

~~~
ShardPhoenix
Java hate is overblown, but compared to say Scala (I have professional
experience with both) it makes a lot of relatively trivial things (like basic
data-holding classes and operations upon them) more painful and verbose than
they need to be.

~~~
eropple
On the flip side (and I too have professional experience with both), Scala can
very easily make simple tasks _really hard to read later_.

There's a balance. Neither is optimal. (I think C# comes very close to what
I'd call "perfect", but it doesn't run anywhere I'd want to use it.)

~~~
ShardPhoenix
I agree - in particular, for advanced Scala libraries it can be hard to
understand the source, which can make them hard to use without thorough
documentation which is often lacking.

------
vijucat
"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.

~~~
dllthomas
There seem to be a couple questions here which could cast things in a
decidedly better/worse light.

If the test is open book, then "I can't manage to look up how to deal with
stdin and stdout in Java" is decidedly more damning than "I can't remember".

Further, if there is a requirement that you use the same language for all of
the answers, choosing Java when you know Java best makes sense. If not,
choosing for that problem Java (when you don't firmly remember how to do
normal IO!) is itself a bad decision, when you likely would have got full
marks for

    
    
        #!/bin/sh
    
        cat

------
noname123
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.

~~~
notimetorelax
Some of the things you mentioned I would categorize as non-essential, but
putting Lucene and Hadoop into the same category seems unreasonable to me.
These tools do solve real world problems and they are absolutely non-
superficial. If anything such lists show how versatile is the JVM.

------
matdrewin
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/](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."

~~~
AlisdairO
I think part of the hate may come from people trying to code Java in a text
editor rather than an IDE. Java's verbosity/class-heaviness really doesn't
bother me at all when I'm in an IDE. OTOH, coding java in a text editor is
pretty frustrating.

~~~
peterashford
That's a fair point. Programming in Java was what made me move from Emacs to
Netbeans. Well, at least for Java, HTML, Javascript etc.

It's an environment that needs an IDE because of the large number of libraries
and the large number of features delegated to libraries rather than the core
language (which is an architectural decision that I approve of, BTW)

------
rdtsc
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.

~~~
WoodenChair
I'm sooo sick of the tools analogy when it comes to programming languages. A
programming language is not simply a tool like a hammer. A hammer does one
thing well, a programming language is a means of expression. It's more akin to
a natural language like Spanish than a "tool" as we generally think of the
word.

Yes, in the broadest sense of the word, Spanish is a tool. So is a programming
language, but the analogy is stretched and stale. The image it puts in
people's minds is not super helpful. And if we must use such a broad word as
tool - let's acknowledge that it's really a collection of tools (every API,
bit of syntax, and language feature is a tool).

~~~
rdtsc
> It's more akin to a natural language like Spanish than a "tool" as we
> generally think of the word.

I still say it is a tool, just a tool with many buttons and settings. English
is a natural language that I learnt (it was my 3rd natural language) primary
to read and understand computer related materials (books, keywords,
instructions). It was absolutely a tool just like a hammer is a tool to drive
a nail in. It turns out to be a very beneficial tool but a tool nevertheless.
I would never bother spending time learning the etymology of words or finding
all the tenses or declensions (but some do and derive great pleasure from
that).

~~~
WoodenChair
I don't think you read what I said - I said it is a tool in the broad sense of
the word (one as you put it with many buttons and settings - I pointed out
those APIs, syntax, etc) - it's just a shitty analogy because the broad sense
of the word means something different than the common use of the term "tool".

------
eranation
> 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](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.

~~~
vorg
> one day you'll get to use Java 8

Only new Java projects would actually use the Java 8 features anytime soon.
Existing Java codebases will stick to their Java 6 installation for a long
while. It could be years before lambdas are used to any significant degree.
Look at how long it took for many Java 1.4 shops to actually upgrade to Java
5, let alone encourage developers to use its features. Even today a lot of
places still allow and even encourage use of collections classes without the
generics specified.

~~~
huherto
You can start using Java 8 as soon as you are willing to move. I don't think
there are many breaking changes in the new version. Just give it a few months
to be really stable. Last week , it took me around ten minutes to move one
application from 6 to 7.

~~~
georgemcbay
"You can start using Java 8 as soon as you are willing to move."

As long as you aren't writing Java code on Android, in which case you're still
stuck at Java 6 (with a very small subset of Java 7 features that were added 3
years after Java 7 came out).

Not the fault of the Java language, really, but it is incredibly annoying how
unclear Google has been on the future of their dialect of Java post the Oracle
lawsuit.

~~~
timothyb89
It's worth noting that Android 4.4 does support pretty much all JDK7 features
(multicatch / try with resources / etc), finally. I've run into the occasional
missing method from some of the newer class libraries, but nothing too
serious.

Of course, if this is any indication it'll be several years before its safe to
use even JDK7 features considering Android's update trends, let alone JDK8 ...

~~~
vans
you should consider using Scala on android. works really well for my projects.

~~~
smrtinsert
Which scala android project are you using?

------
Pitarou
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:

    
    
        public class HelloWorld {
          public static void main(String[] args) {
            System.out.println("Hello World.");
          }
        }
    

So to answer the interview question, I just need to figure out how to open
_stdin_. At a guess, maybe something like _System.in.readln_ will do it? Let's
look in the class libraries.

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)
     

These methods just read bytes! I want a _String_ , or at least a _char_. And
Java uses multibyte characters. Can I get away with casting _bytes_ to
_chars_? I don't know. Maybe it was one of the CORBA methods after all? Or
maybe ... I'm stuck!

I figured it out in the end, but only through pure luck: I need to wrap
_System.in_ in a _java.io.InputStreamReader_.

~~~
cbsmith
> "Can it really be that hard to figure out how to open stdin?"

? In most runtimes stdin is opened before you start. Certainly is true in the
case of Java.

> So to answer the interview question, all I need to do is open stdin.

No, you also need to "open" stdout. More importantly, you have to figure out
how to read and write to streams without losing data (which you'd think would
be easy but evidence indicates otherwise).

~~~
Pitarou
Sorry, I'm getting the terminology wrong. I mean "read from".

------
espinchi
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.

~~~
cbsmith
But doing a simply copy of stdin to stdout is actually quite easy in Java.

~~~
PeterisP
Yes, but it requires knowing library functions that many Java programmers
wouldn't have used for years and would need to look up; you just don't
interact with console in Java-world not nearly as much as, say, in Perl-world.

Doing it through, say, docs.oracle.com to check what's the stdin interface -
that is quite easy, but writing it on a whiteboard from scratch would fail
many Java developers.

~~~
cbsmith
> Yes, but it requires knowing library functions that many Java programmers
> wouldn't have used for years and would need to look up; you just don't
> interact with console in Java-world not nearly as much as, say, in Perl-
> world.

People keep thinking that there are special functions involved in this
solution for interacting with the console (which by itself is telling). Let's
pretend it was just copying from an InputStream to a PrintStream. Those are
both interfaces that most Java developers should be quite familiar with.

~~~
PeterisP
Where would your code see an InputStream? "Interacting with console" is overly
specific, yes. However - the other two usecases are handling files and network
sockets, and in the java world, you generally _don 't_ touch streams of bytes
or lines even in those cases.

The unix approach of treating most things as streams of bytes or lines tends
to be abstracted - if I'm writing socket-based communications, then an
InputStream exists there; but if I'm making web requests, then it's through a
library where no streams are exposed. If I'm writing a logging library, then a
PrintStream exists there; but if I'm doing proper logging, then again, it uses
a library that doesn't expose any streams to a public interface, just the
appropriate methods. Custom file formats would involve handling streams
directly, but general practice in line-of-business apps nowadays is to never
do that - you just [de]serialize to json/xml/something else standartized; and
again that's done by a library that uses streams but doesn't expose them.

These things are trivial to do in java, but what I'm saying is that java is
very often used in large codebases that don't touch raw streams at all.
Students in java lessons use InputStream&PrintStream, but after starting work,
promptly forget what the methods are called as they're used rarely.

~~~
cbsmith
> However - the other two usecases are handling files and network sockets, and
> in the java world, you generally don't touch streams of bytes or lines even
> in those cases.

I think you live in a pretty rarified Java world.

> The unix approach of treating most things as streams of bytes or lines tends
> to be abstracted - if I'm writing socket-based communications, then an
> InputStream exists there; but if I'm making web requests, then it's through
> a library where no streams are exposed.

Except if you want to handle large amounts of data efficiently, you end up
using streams to read and or write those web requests.

> Custom file formats would involve handling streams directly, but general
> practice in line-of-business apps nowadays is to never do that - you just
> [de]serialize to json/xml/something else standartized; and again that's done
> by a library that uses streams but doesn't expose them.

...and I guess you never have to debug anything or understand what is
happening underneath?

> Students in java lessons use InputStream&PrintStream, but after starting
> work, promptly forget what the methods are called as they're used rarely.

Then why do you think they teach 'em? Aren't all subsequent concepts built on
top of them?

~~~
sixbrx
> Except if you want to handle large amounts of data efficiently, you end up
> using streams to read and or write those web requests.

No you wouldn't, unless you're working on some tiny project where using raw
servlets _might_ be justified (though I'd be highly suspicious of anyone doing
raw servlets). Most any other framework will provide higher level abstractions
such as Play's Iteratees or variations of sendfile to handle the streaming for
you. You're job is usually just to configure the proper marshaling setup so
that your higher level object(s) delivered by your controller methods are
properly serialized by the lower levels of the framework.

Occasionally you may need to actually write marshalling code but you should
definitely be wary that you're doing it wrong if so.

------
dminor
If you're writing mediocre code and are happy with it, the problem might not
lie with the language.

~~~
elwell
If mediocre code gets the job done faster and it's reasonably maintainable,
but you avoid it due to code-idealism, the problem might not lie with the
language.

~~~
krisgenre
If your code is "reasonably maintainable", I don't think you can call it
mediocre code.

------
sadfnjksdf
> 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.

------
drblast
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.

~~~
torrent-of-ions
> 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.

I'd say this ground is well and truly occupied by Common Lisp. Java occupies
some other ground which is neither quick nor succinct.

------
rspeer
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.)

~~~
rsfinn
> (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.)

Which one is that? As far as I can tell, the "new" 6.170 (6.S197) uses Python
(or at least used it in the fall of 2011).

(I gather by its new subject number that it is no longer a part of the core
requirements, being largely supplanted by 6.005, which ironically appears to
use Java. Of course, when _I_ took 6.170, we used CLU. Boy, am I old.)

~~~
rspeer
I haven't actually interacted with the MIT curriculum in years, so I might be
missing the point, but I was looking at the syllabus for 6.170 Spring 2013:
[http://ocw.mit.edu/courses/electrical-engineering-and-
comput...](http://ocw.mit.edu/courses/electrical-engineering-and-computer-
science/6-170-software-studio-spring-2013/calendar/)

I guess it would be true that 6.005 is the "main" software engineering course
now, not 6.170.

------
exabrial
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!

~~~
ketralnis
Have you ever interviewed programmers? Have you ever attended a job interview?

(1) This is an interview question, he's not asking you to be a professional
stdin->stdout copier

(2) this isn't a micro optimisation problem:

    
    
        > The first question on the quiz is a triviality, just to let the candidate get familiar with the submission and testing system
    

(3) A surprising number of programmers can't program. Basic warmup questions
are a good thing and can save a lot of your time
[http://blog.codinghorror.com/why-cant-programmers-
program/](http://blog.codinghorror.com/why-cant-programmers-program/)

(4) Even if this isn't his attempt, there's genuine depth to even this
problem. If you do the obvious

    
    
        a = get_byte()
        while a != EOF:
            send_byte(a)
            a = get_byte()
    

There's a surprising amount of work going on behind the scenes that you can
dive into discuss how I/O works, when would you do this using blocking vs.
non-blocking I/O, when should you do your own buffering or let the
language/library do it for you. But it's short enough to get started to get to
those points very quickly.

(5) I wouldn't hire/not hire someone based on style alone, but you can get a
pretty good feel for it from short programs that actually work. If the tasks
or snippets on which you interview are too short to be complete programs, you
miss a lot of organisation and "shape of the code" kind of stuff from their
style.

(6) Interviews are tough as an interviewee. Professional programmers aren't
professional job interviewers and often it can be hard to read their mind to
see what they are looking for in a particular question. "It's open ended, take
it where you like" usually doesn't mean what it says on the tin. As far as
going from "here's a question" to "here's an answer" with little ambiguity
this is one of the better FizzBuzz type questions I've seen.

~~~
ojbyrne
My initial impulse would've been

#!/bin/sh

cat

~~~
threedaymonk
You can go one better: just symlink cat and avoid an unnecessary exec.

------
itsadok
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.

------
xkarga00
"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

------
pnathan
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.

~~~
cbsmith
> Hum. If that's a positive spin on Java, you can count me unimpressed.

I think you missed the point of the article.

------
m0g
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_.

------
guelo
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);
      }

~~~
cbsmith
You know, I kind of thought he was joking that Java programmers messed this
stuff up.

I was so wrong.

Three things wrong. The first is pedantic: you need to import IOException. The
second though is one of those "scream out loud at the universe* questions: why
the heck are you calling print() instead of write()?

Finally, do you think _maybe_ you might need to worry about buffering of
System.out's stream?

~~~
dlubarov
> Finally, do you think maybe you might need to worry about buffering of
> System.out's stream?

print() won't flush to the console unless you pass '\n' and auto-flushing is
on. It will flush its internal buffer, but that's okay! The default System.out
uses a BufferedOutputStream anyway:

    
    
        FileOutputStream fdOut = new FileOutputStream(FileDescriptor.out);
        ...
        new PrintStream(new BufferedOutputStream(fdOut, 128), true)
    

So using print() instead of write() shouldn't cause any extra system calls,
although there many be a small CPU cost.

Obvious, right? Don't you love java.io? :)

~~~
cbsmith
> The default System.out uses a BufferedOutputStream anyway

Yes, which is the _problem_, not the _solution_.

To clarify: the problem _isn 't_ that the code makes too many syscalls.

~~~
dlubarov
So what are you saying is the problem then? That writing to the
BufferedOutputStream for each character is CPU-inefficient and he should be
doing this?

    
    
        public static void main(String[] args) throws IOException {
            byte[] buffer = new byte[1 << 12];
            for (;;) {
                int nRead = System.in.read(buffer);
                if (nRead == -1) return;
                System.out.write(buffer, 0, nRead);
            }
        }
    

If so, fair enough, but it's reasonable to go with the simpler solution if
you're not given any particular performance requirements.

~~~
cbsmith
No, I'm saying you are _already_ using a BufferedInputStream and a
BufferedOutputStream. That is the problem: you aren't guaranteeing your output
matches your input.

Try doing this:

    
    
        dd if=/dev/random of=test_file bs=4000 count=100
        java YourClass < test_file > test_output
        diff test_file test_output

~~~
cbsmith
Here's the simpler, likely slower, but nonetheless actually _correct_
solution:
[https://gist.github.com/cbsmith/9755809](https://gist.github.com/cbsmith/9755809)

~~~
dlubarov
Oh, gotcha. The code above with "byte[] buffer" also works since write(byte[],
int, int) flushes.

------
malanj
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.

------
ryanobjc
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.

~~~
ryanobjc
Following up, the main argument is "java doesnt have hashes built in".

Well neither does C, C++ as well. Nor does Scala actually.

There are a lot of good things about Java, namely the JVM, interfaces, great
libraries, reflection and code generation, etc, etc. For example libraries
like jmock/etc.

~~~
zoodle
C++ does include hash functions. Of course, most will just use
std::unordered_map.

[http://www.cplusplus.com/reference/functional/hash/](http://www.cplusplus.com/reference/functional/hash/)

~~~
ryanobjc
That isn't part of the language, that's part of the standard library. Just the
same as java, which has a standard hashing function, AND hash table/map.

Ultimately, where does the language end, and the standard library begin? Whats
the real difference? Yeah, so C++ and Java don't have built in syntax for hash
tables. That's it?

------
piokoch
"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).

------
elwell
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.

~~~
etfb
I knew a guy named Steve who ensured job security using Delphi. He wrote this
malevolent and semi-sentient framework called The Framework, that managed to
combine the ugliness of COBOL with the programmer-friendliness of... well,
COBOL, now I think of it. Delphi has a couple of different flavours of
inheritence built in -- object inheritence, controls owning subcontrols,
TFrames embedded in TForms -- but The Framework increased that number
somewhat. From memory, I think I counted nine different kinds of hierarchy,
all intermingling in weird and utterly undocumented ways.

For all I know, he's probably still working there. The poor, poor bastard.

~~~
xentronium
Have you submitted your story to thedailywtf?

~~~
etfb
I often considered it, but this was over a decade and a half ago, and I don't
recall enough details to make a good story out of it.

------
pacoverdi
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."

------
alttab
He doesn't like java.

~~~
cbsmith
He does. People are missing the point.

~~~
alttab
No, pretty sure he was being demeaning to the point no developer would read
this and want to work in java.

~~~
cbsmith
Yeah, not getting his point. Sure, you wouldn't want to work with it, but the
reality is that letting go of the idea of writing perfect code helps you just
getting it done. It's sickening, but it's a valid point.

~~~
alttab
Which is not a viewpoint from someone who "likes" it. They have an objective,
professional point of view. He doesn't like it though.

------
gaelow
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.

------
jbverschoor
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

------
lawl
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...

    
    
        #!/bin/bash
        cat
    

If people can't come up with a different solution they probably just suck...

~~~
cbsmith
> I'm a professional Java dev and couldn't do this from the top of my head
> without System.* documentation.

All that documentation will show you is that you use System.in to access
standard input, and that it is an InputStream, and you use System.out to
access stand output, and it is PrintStream. I'm sure an interviewer would be
happy to provide you with those prompts. Could you solve the problem with that
help?

~~~
lawl
Nope, Had to look at the javadoc for those two classes too. I guess you don't
memorize this stuff when Ctrl+Space in eclipse constantly tells you what you
need.

And it probably doesn't help that the java.io package is also really horrible.

read() returns byte[] but print() accepts only char[], so you'd need to cast
or use write() which accepts byte[], but you need to pass it an offset and the
length too: write(byte[] buf, int off, int len). Eh, that's just stupid. I'm
happy eclipse tells me that stuff...

If I had to do this at an interview in Java, from the top of my head I'd
probably ask if it's okay if I use Apache Commons IOUtils and try to
IOUtils.copy().

But again, the article talks about language of your choice. I was just a bit
shocked when I was able to write this in C and perl without autocomplete even
if I practically never use C or perl.

Makes me wonder if it's really the IDE's that make you not memorize the
standard library. Or if Java's standard library is really that horrible.

I think it's a combination of both.

Or maybe because I usually don't deal with this stuff in Java while
implementing boring business logic.

Also, C:

    
    
        #include <stdio.h>
    
        int main(){
            char strbuf[1024];
            while(fgets(strbuf,1024,stdin)){
                puts(strbuf);
            }
       }
    

Perl:

    
    
        perl -e 'while($a=<>){print $a}'

~~~
raiph
Fwiw, as pointed out elsewhere you can simplify the Perl 5 to:

    
    
        while (<>){ print };
    

Fwiw, in Perl 6, the canonical incantation is:

    
    
        .say for lines
    

where:

* thing.method calls method 'method' on thing (where thing is an object, or something that can behave as an object, which, in Perl 6, is any value). In the code above the 'say' method prints its arg, followed by a \n, to stdout.

* If thing isn't specified, the current topic (aka "it" aka $_) is assumed, so .say is being called on "it".

* 'for' sequentially sets the current topic ("it") to each of the items in the following list of things.

* 'lines' lazily reads lines (next chunk of text up to the next \n) from somewhere. The default somewhere is stdin.

A simpler incantation is:

    
    
        slurp.say
    

which slurps all of stdin as a list of lines and then says them all, but slurp
isn't lazy, so it'll wait till it's read all of your stdin before writing any
of it to stdout.

------
cbsmith
So, this discussion has already demonstrated how Java programmers get this
stuff wrong. Kind of head shaking stuff. Here's a simple implementation. No
exception handling logic (and some would no doubt quickly with allowing throws
of Throwable), on the assumption that anything that actually generates an
exception would actually be the kind of thing you'd not want to recover from,
and it uses synchronous, single byte at a time (buffered) reads & writes, but
it actually runs reasonably efficiently as compared to using most scripting
languages.

[https://gist.github.com/cbsmith/9755809](https://gist.github.com/cbsmith/9755809)

~~~
sfjailbird
> on the assumption that anything that actually generates an exception would
> actually be the kind of thing you'd not want to recover from

In that case it does exactly the wrong thing, by declaring checked exceptions
in the method signature, which client code will be forced to deal with.

If you don't even understand how checked exceptions are supposed to work then
no wonder you are hurting yourself on the language.

~~~
cbsmith
> In that case it does exactly the wrong thing, by declaring checked
> exceptions in the method signature, which client code will be forced to deal
> with.

> In that case it does exactly the wrong thing, by declaring checked
> exceptions in the method signature, which client code will be forced to deal
> with. > > If you don't even understand how checked exceptions are supposed
> to work then no wonder you are hurting yourself on the language.

It's an error that you don't have a way to recover from. Reporting an error
and leaving it to the client code (or in this case, the parent process) to
deal with it, exactly as specified by the declaration of the method. That's
actually exactly how exceptions are supposed to work.

------
nbevans
1\. Functional programmer makes bold factual statement. So "bold" that it is
almost perceived as trolling by imperative programmers. 2\. Hacker News' usual
suspects fail to grok remotely what he is even saying. 3\. GOTO 1.

~~~
JoeAltmaier
Its pretty much a fact of communication that if you can't make yourself
understood, you've failed at it.

~~~
nbevans
It's a common expression though what his post was based upon.

"[You don't get paid to write software as a Java dev, you get paid and judged
by the amount of lines of code you write.]"

If Java and other imperative devs haven't heard that before then they need to
consume more sources of knowledge and widely held opinions.

The quip about being dissolved of any real responsibility as a Java dev is
stereotypical of course. And it doesn't solely apply just to Java but to the
general mindset shared by the various big imperative enterprise languages. It
is _possible_ to use such languages in a _cleaner_ fashion (with lots of hoop
jumping) but rarely does the opportunity present itself in such enterprise
environments because of politics and backwards thinking. Additionally, _why_
should you have to incorporate countless additional libraries and techniques
just to "bend" the language to what it should have been in the first place?
That's what everyone ridicules JavaScript for doing.

The best, most experienced programmers will naturally gravitate toward
functional practices; which is basically SOLID in OOP land. Unfortunately, at
the moment, only the luckier (or pluckier?) ones will actually find themselves
in a job that lets them use a real functional language that deprecates the
need to jump through so many hoops just to achieve a maintainable and
immutable (and all the other good stuff) design.

------
druska
Maybe instead of grinding out code he hates, he should find something he
enjoys coding, or maybe don't code at all.

------
ctrager
I have a decent amount of experience coding in big codebases using C#/Java -
compiled, strongly typed languages - on the one hand, and Ruby/Javascript -
interpreted, loosely typed - on the other. When I'm working in a big,
unfamiliar codebase, I'm grateful for the help that the IDEs (Visual
Studio/Intellij/Netbeans) can provide with refactoring, dead code detection.
Would it be correct to say that because of the so called verbosity of Java,
the IDEs are that much better at giving you instant feedback that you have
broken something?

------
neilellis
Hey I'm trying to find someone who can build a shed for me, and all these
qualified structural engineers I have interviewed don't even know the
difference between a pozidrive and a phillips screwdriver. What the HELL do
they teach them at University these days!

(sigh) I despair, honestly. Please folk, take the time to see how some of the
largest scale software on the planet runs on the JVM. Horses for bleedin'
courses folk.

Personally I write my software in Bash, Java/Kotlin and Javascript -
_depending on the context_ each of these have proven to be excellent
technologies.

------
ArtDev
Reminds me of the old joke: Knock knock. "Who's there?" ......(pause).........
"Java"

------
todd8
Why do these kinds of posts produce so much noise on HN? Its not because
HNewsers are silly or stupid. Its because programming languages really do
matter. However, experience with Java isn't enough to have a wise perspective
on Java and experience with Javascript isn't enough to have a wise perspective
on Javascript. All languages aren't alike and all languages aren't equally
good (even if Turing equivalent). University exposure to various programming
languages is helpful, but programming in a language amongst other experienced
programmers is more valuable.

I learned C while in grad school, but I really learned it at IBM while working
on the Unix kernel. That gave a useful perspective on the strengths and
weaknesses of C. So I can say that Java has some real advantages over C for
certain kinds of work while C is the right language for kernel work.

Here, on HN, I've learned that Java programmers like programming in Java and
that Javascript programmers love programming in Javascript. But please don't
pontificate on how wonderful functional programming is in Javascript if you
haven't got a reasonable amount of experience with a real functional language
(OCaml, Haskell, etc.). Or that Java is better than Python because [whatever]
unless you've really programmed in Python too.

------
hyp0

      ...this question comes up so often you'd think they'd just figure out that the
      chaining of streams is somewhat difficult and either make helpers to create various
      combinations or rethink the whole thing
    

[http://stackoverflow.com/questions/309424/read-convert-an-
in...](http://stackoverflow.com/questions/309424/read-convert-an-inputstream-
to-a-string#comment152598)

    
    
      java is a blue collar language
    

James Gosling, _The Feel of Java_
[http://www.dfjug.org/thefeelofjava.pdf](http://www.dfjug.org/thefeelofjava.pdf)

Java is indeed very workmanlike. Straightforward, predictable, reliable.

My observation is that the Java standard libraries (packages) are like a
highly skilled and conscientious C programmer trying to write OOP. The don't
want to cut off too much power from you. And that means you have to specify
everything - _exactly what kind of list do you want?_ In scripting languages
you don't, because most of the time it really doesn't matter. (BTW: If you
read some of the source, it is often written in a C-like style rather than
Java-like).

The low-level style of libraries is at least half the reason Java has lost out
to Python/Ruby etc. But also for its wins.

------
atiffany
I like the piece but I'm afraid some people will just read the title on the
front page and assume that someone reputable is actually endorsing Java.

~~~
cbsmith
...except he _is_ endorsing it.

~~~
dllthomas
Maybe he's not "someone reputable"?

------
carsongross
If java was brainfuck, and we still got the JVM out of it, it would all be
worth it.

~~~
etfb
My first thought when I saw that trivial programming question was to write it
in Brainfuck.

My second thought was to come here to the comments to see how long it would be
before the attempts started.

My third thought was, if you're allowed to use any language at all, I'd go for
code golf. Not sure it's possible to do it in fewer characters than:

    
    
        #!/bin/sh
        cat

~~~
neilellis
#!/bin/cat -

~~~
etfb
Clever. You win one internet.

------
snowryd88
I bet someone is going to post an article named "Why I hate Java"

------
wmnwmn
I like Java well enough and I don't know any other way at the moment to make
an app that can run both on the desktop and over the web, on all major
platforms, in exactly the same way.

However it is true that reading a stream from stdin is a big pain. More
importantly it's also true that students learn an over-objectified style of
Java programming in school which generally produces very bad code. Students
tend to create too many layers of objects and to over-use inheritance,
resulting in an inflexible structure with many opaque interlinks between
objects. In the real world specs change at any time, and one must program in
such a way that unanticipated features can be added. Deciding what blocks of
code should be broken into shared routines remains, in my view, something of
an art form, and one that the current Java-based programming curriculum does
little to develop.

------
GotAnyMegadeth
> But it is not a language I would choose for answering test questions, unless
> maybe the grade was proportional to the number of lines of code written

Related to this: At Uni we had a terrible lecturer for our first year C
programming courses. We had a team project that none of understood. A few days
before the submission, when we didn't have anything that would compile,
someone got hold of the marking system. The marking was automatic, and up to 5
of the 25 marks were awarded for the code:comment ratio. We deleted the lines
that were causing it to fail to compile, then copy n pasted the whole code
below again, but as one giant multi-line comment, securing us a 1:1
code:comment ratio. We got 7/25, 5 of which was for "Legibility and good
coding practices".

------
kang
Watching videos of Petr Mitrichev, who is arguable the best sport programmer,
I feel that Java does allow you implement that logic in your brain, fast
enough. I feel this is enough attention a mere tool should be given to, given
that the main goal is actually solving the problem.

------
ChrisGaudreau
There's only one way to solve a given problem in Java? Tell that to my
AbstractFactoryPoolBean.

~~~
nemasu
Don't forget to use Generics.

------
molbioguy
_But when you learn Java, there aren 't any powerful language features you can
use to solve many problems._

I know it's not pure, but Java does force you to think in an object-oriented
way. And there are problems where that's an advantage.

~~~
chriswarbo
Every Java file consists of a load of package imports followed by a class
definition. In Java, packages and classes are not objects.

The majority of a class's definition is spent defining methods. In Java,
methods are not objects.

A large amount of method code is spent looping, branching and exception
handling. In Java, loops, branches and exception handlers are not objects.

Scattered liberally throughout all of this, there are type annotations. In
Java, types are not objects.

Could you please explain how Java forces me to think in an object-oriented
way?

~~~
peterashford
Riiiight. So by that metric, C++ and Smalltalk are OOP either. What exactly
_is_ OOP in your world?

~~~
chriswarbo
C++ isn't particularly OO.

Smalltalk is, since numbers, booleans, etc. are objects, classes are objects,
methods (and functions in general, known as "blocks" in Smalltalk parlance)
are objects.

Likewise, the only control flow mechanism is the method call. Branching
(if/then/else) is a method of the boolean objects. Loops are done via the
"times" method of numbers. It's turtles all the way down.

------
norswap
Got to "But when you learn Java, there aren't any powerful language features
you can use to solve many problems. Instead, you spend your time learning a
body of technique for solving problems in the language. Java has hashes, but
if you are aware of them at all, they are just another piece of the immense
Collections library, lost among the many other sorts of collections, and you
have no particular reason to know about them or think about them." and then I
stopped.

If you have to be taught about dictionaries (1), you're a crappy programmer
anyway.

(1) I will accept the denomination "map" also, but they are not called
"hashes" damnit.

------
laichzeit0
Over the years I've found Java to be too chatty and a pain in the ass to use
directly. I mainly use Groovy now which also runs on the JVM.

Just yesterday I wrote some extensions for Solr, you can do it in Groovy (hell
even Javascript).

There's very little point in writing things in pure Java these days.
Especially if you're just using Java libraries and gluing pieces together, use
some scripting language that compiles to bytecode.

Here's one cool thing about Java: The documentation is probably the best of
any development ecosystem out there. APIs are wonderfully documented. For an
extreme dose of hilarity, compare Javadocs to Nodejs documentation.

------
benjamincburns
I agree that there are plenty of warts to be found in various well-known Java
libraries, and that there is a shocking amount of poorly architected Java out
there, but I can't agree that it's the language's fault.

Java has become the language of "the noob." For a very large percentage of
programmers, it's the first language that's presented to them. As such, there
are endless examples of Java projects written by people who are still
struggling with basic flow control, let alone project architecture. Some of
these projects are written by smart people, and they're genuinely useful. As
an example, think of the research biologist who's writing code for her thesis
- code for which there's probably no measurable market.

Because it's the language of the noob, it's really easy to gain the kind of
experience this author is describing. The kind where you just glide along,
"turning the crank" not really learning anything for a long, long time. People
come away honestly believing that because they've worked with the language for
so long they're experts. That there's nothing left which will surprise them,
or change the way they work in this language.

I've seen a lot of cases where these people bump up against some really cool
things and never realize it. Because they don't understand it they quickly
write it off as bad code/architecture/naming.

One of the most common examples I've seen of this is when people pull class
names from the Spring application framework core, parading them around with no
context and no knowledge of why they exist or why they might be _incredibly_
useful, let alone why they sometimes make Java a joy to work with.

"AbstractSingletonProxyFactoryBean??! I don't care what it is, that's just
_stupid_!" [1]

How ignorant.

> After all, you produced 576 classes that contain 10,000 lines of Java code,
> all of it seemingly essential, so you were doing your job.

I can agree that Java is a verbose language, and sometimes it's really
difficult to express an abstraction succinctly as compared to some other
languages. I can agree that it's also easy for people to run wild and over
abstract. However, I think it's just as likely for people to mistake well
abstracted code for needlessly verbose code.

> And nobody can glare at you and demand to know why you used 576 classes when
> you should have used 50...

Without a specific case, it's hard to figure out what's really going on here,
but if this is a primary target metric, I'd say you're prioritizing the wrong
things.

> ... because in Java doing it with only 50 classes is probably impossible.

Just throw separation of concerns out the window and you can write just about
anything in one class.

1:
[http://docs.spring.io/spring/docs/2.5.x/api/org/springframew...](http://docs.spring.io/spring/docs/2.5.x/api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html)

~~~
Daishiman
> I can agree that Java is a verbose language, and sometimes it's really
> difficult to express an abstraction succinctly as compared to some other
> languages. I can agree that it's also easy for people to run wild and over
> abstract. However, I think it's just as likely for people to mistake well
> abstracted code for needlessly verbose code.

See, this is a mistake. Abstraction is not an end in itself; it's there to
make life easier and to make things easier to undestand.

Bloat is one of the many things abstraction is supposed to reduce; if an
abstraction is _increasing_ cognitive overhead and reducing the signal-to-
noise ratio, then we've got ourselves a problem.

For reasons that I cannot comprehend, Java seems to be the only language that
seems to have excessive abstraction as a requirement. Not as a convenience,
not as a nicety, but as a _requirement_ to do things like Dependency
Injection, Inversion of Control, Unit Testing, Mocks, logging, etc. The fact
that you need to use entire frameworks to accomplish the functionality that in
many languages is covered by a couple functions in a built-in module is a
mystery to me.

I'm not the wisest expert, but I have over a decade in a field and I've worked
in all sorts of different software, and Java (along with some very badly
written .NET systems) seems to be the only technology that requires me to grok
a dozen files to understand basic workings of MVC systems with the most
elementary of logic. And the thing is, 90% of that code is absolutely useless
to the extent of the use cases proposed by the system, and none of its
potential extensibility is actually used. You have to ask yourself how come
neither Python nor Haskell have these monstruous frameworks.

Sure, it's a lot better now, after having caught up 8 years behind the rest of
technologies, but the foundations are notoriously complicated for things that
are effortless with other tools.

This points to me towards the idea that Java abstractions have simply been
poorly chosen.

~~~
lmm
In Python there simply doesn't seem to be a DI/IoC container available. So you
end up half-assedly writing your own, or just using spaghetti code. I'm
tempted to suggest that Python doesn't have these frameworks because it
doesn't bother to support writing large programs. Likewise with testing,
there's the unittest module but it's not really integrated with a build system
or anything else. Java does in fact have some standard library functions for
logging, but no-one wastes their time learning them - if all your real
projects are going to use log4j, why not just use log4j all the time?

There are certainly unnecessary parts - there's a hell of a lot of bloat in
spring - but just doing without frameworks entirely is not the answer.

~~~
icebraining
_In Python there simply doesn 't seem to be a DI/IoC container available._

Sure there are. There's even a version of Spring for Python. It's just that
nobody uses them. You're free to guess why.

~~~
watwut
Because they are useful only after the project grows big. People who use them
on small projects do it out of habit.

Which only confirms what parent comment wrote.

------
wobbleblob
Why I like it when people are overconfident pompous noobs on the internet

------
jaimebuelta
I think this is a very advanced trolling... X-D

A great application of Poe's Law[1]

[1]
[http://en.wikipedia.org/wiki/Poe's_law](http://en.wikipedia.org/wiki/Poe's_law)

------
elchief
I couldn't care less what language I am using. I care about the quality of the
libraries. That's what helps you get shit done fast. And JVM has a shit-ton of
high quality libraries.

------
koevet
It's ironic how this kind of Java bashing comes from a Perl guy.

------
blazespin
Java is one of the best, most elegant choices for certain types of problems.
For other types of problems, it is horrid. This can be said of many
programming languages.

------
josephpmay
Very misleading title for a great article. I will probably point people to
this in the future when they ask me why I don't like Java (yet continue to use
it).

------
olalonde
> My current employer uses an online quiz to pre-screen applicants for open
> positions. The first question on the quiz is a triviality, just to let the
> candidate get familiar with the submission and testing system. The question
> is to write a program that copies standard input to standard output.
> Candidates are allowed to answer the questions using whatever language they
> prefer.

I wonder if "cat" would count as a valid answer.

------
nemasu
I hate Java, and loved this article. Not what I was expecting. Now excuse me
as I have 213 more classes to write each containing about 2 lines of real
code.

------
mrmondo
"What are you? A RAM salesman?"

------
ksikka
I love this. Keep calm and java on.

------
louisdefunes
Is it me (not a native english speaker) or isn't this article all but
sarcastic?

------
bakhy
i certainly wouldn't want this Negative Nancy paying me any compliments ;)

------
nu2ycombinator
He has a point. Once I used this online technical interview questions.
Understanding the submitting output of the program through using java took
longer than the Python or Ruby.

------
sreya
Copy standard input to standard out? It's like 5 lines of code in Java

Scanner scan = new Scanner(System.in) while(scan.hasNext()) {
System.out.println(scan.nextLine()+"\n") }

~~~
cbsmith
Oh good lord. This one adds in Scanner!

How do you think this code will handle binary data? How do you think it'll
handle a simple two line text file?

~~~
ASneakyFox
There is no one solution fits all. Especially if the problem is imaginary.

~~~
cbsmith
> There is no one solution fits all. Especially if the problem is imaginary.

Yeah, but there are solutions that actually solve the problem.

~~~
ASneakyFox
what exactly is the problem? you cant just make up problems and ridicule the
code for not solving them when the coder had no idea he was supposed to be
solving them.

This solution (and whatever solution you might have in mind) likely both dont
solve all sorts of problems. for instance what if there is a power failure and
you lose all the output? is it persisting to disk? what if new input methods
that arent even thought of it come to exist 5 years from now, is it compatible
with that?

~~~
cbsmith
> This solution (and whatever solution you might have in mind) likely both
> dont solve all sorts of problems. for instance what if there is a power
> failure and you lose all the output? is it persisting to disk? what if new
> input methods that arent even thought of it come to exist 5 years from now,
> is it compatible with that?

You are missing the point. The code doesn't work. I'd love to hear any
interpretation of the problem where that code actually is correct.

------
Nekorosu
Nice article! After reading it I can tell I like Java too.

------
general_failure
The issue with java is not the language. The language is great.

The issue is the totally over-engineered APIs

------
Ramonal
I like java since I learned it.

------
z3phyr
I really love the JVM. Inversely its related to Java™. I hate it passionately.

------
ASneakyFox
This post is nerdbait. Not hn material.

------
happycube
"cat -" :)

------
cpdean
what is this, fonts for ants?

~~~
cromwellian
I feel like I'm taking crazy pills! I invented the piano key necktie! What
have you done Derek?!

------
suyash
I love Java :)

------
anon4
Isn't it all just

    
    
      StreamUtils.copy(System.in, System.out)
    

I'm pretty sure there is a function that just copies an input stream to an
output stream in commons-lang.

Still I agree with him - I won't write Java in a test like that. It is almost
impossible to write Java fast without an IDE to autocomplete everything for
you. There are way too many names to remember. I can't even tell you what
package StreamUtils are in or if it's StreamUtils or FileUtils.

~~~
cbsmith
It is pretty much just that... although I think StreamUtils doesn't flush so
you'd need to add that.

------
teemo_cute
I love Java because when you add 'script' to it you have a pretty sweet
language.

~~~
72deluxe
What, JavaFX Script?

------
freeasinfree
Typical ESL Java programmer

------
Ramonal
nice article!

------
ky6b79
Nice article!

~~~
Ramonal
AGREEEE

~~~
ky6b79
：）

