Why I like Java - <AUTHOR> http://blog.plover.com/prog/Java.html <comment><USER4> 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_.

<comment><USER5> 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.

<comment><USER6> > 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.

<comment><USER7> >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.

<comment><USER8> "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.)

<comment><USER9> 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.

<comment><USER8> 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.

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

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> > 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.

<comment><USER11> > 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.

<comment><USER12> Forget the 'cool guys', the best software engineers love Java.

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

<comment><USER13> But you love Java for its exceptions.

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

</comment></comment></comment></comment></comment></comment><comment><USER14> 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.

<comment><USER15> 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.

<comment><USER16> > 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?

<comment><USER15> No. I almost never need to read from stdin, as I said.

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

</comment></comment></comment></comment><comment><USER17> 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.

<comment><USER18> 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.

<comment><USER19> 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.)

<comment><USER18> 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.

</comment></comment></comment></comment><comment><USER20> "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.

<comment><USER21> 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

</comment></comment><comment><USER22> 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.

<comment><USER23> 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.

</comment></comment><comment><USER24> 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."

<comment><USER25> 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.

<comment><USER26> 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)

</comment></comment></comment><comment><USER27> 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.

<comment><USER28> 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).

<comment><USER27> > 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).

<comment><USER28> 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".

</comment></comment></comment></comment><comment><USER29> > 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 - <USER2> 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.

<comment><USER30> > 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.

<comment><USER17> 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.

<comment><USER31> "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.

<comment><USER32> 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 ...

<comment><USER33> you should consider using Scala on android. works really well for my projects.

<comment><USER34> Which scala android project are you using?

</comment></comment></comment></comment></comment></comment></comment><comment><USER35> 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_.

<comment><USER16> > "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).

<comment><USER35> Sorry, I'm getting the terminology wrong. I mean "read from".

</comment></comment></comment><comment><USER36> 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.

<comment><USER16> But doing a simply copy of stdin to stdout is actually quite easy in Java.

<comment><USER37> 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.

<comment><USER16> > 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.

<comment><USER37> 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.

<comment><USER16> > 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?

<comment><USER38> > 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.

</comment></comment></comment></comment></comment></comment></comment><comment><USER39> If you're writing mediocre code and are happy with it, the problem might not lie with the language.

<comment><USER40> 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.

<comment><USER41> If your code is "reasonably maintainable", I don't think you can call it mediocre code.

</comment></comment></comment><comment><USER42> > 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.

</comment><comment><USER43> 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.

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

</comment></comment><comment><USER44> 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.)

<comment><USER45> > (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.)

<comment><USER44> 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.

</comment></comment></comment><comment><USER46> 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!

<comment><USER47> 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.

<comment><USER48> My initial impulse would've been

#!/bin/sh

cat

<comment><USER49> You can go one better: just symlink cat and avoid an unnecessary exec.

</comment></comment></comment></comment><comment><USER50> 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.

</comment><comment><USER51> "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

</comment><comment><USER52> 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 - <USER3> 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.

<comment><USER16> > Hum. If that's a positive spin on Java, you can count me unimpressed.

I think you missed the point of the article.

</comment></comment><comment><USER53> 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_.

</comment><comment><USER54> 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);
      }

<comment><USER16> 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?

<comment><USER55> > 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? :)

<comment><USER16> > 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.

<comment><USER55> 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.

<comment><USER16> 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

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

<comment><USER55> Oh, gotcha. The code above with "byte[] buffer" also works since write(byte[], int, int) flushes.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER56> 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.

</comment><comment><USER57> 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.

<comment><USER57> 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.

<comment><USER58> 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/)

<comment><USER57> 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?

</comment></comment></comment></comment><comment><USER59> "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).

</comment><comment><USER40> 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.

<comment><USER60> 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.

<comment><USER61> Have you submitted your story to thedailywtf?

<comment><USER60> 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.

</comment></comment></comment></comment><comment><USER62> 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."

</comment><comment><USER63> He doesn't like java.

<comment><USER16> He does. People are missing the point.

<comment><USER63> No, pretty sure he was being demeaning to the point no developer would read this and want to work in java.

<comment><USER16> 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.

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

</comment></comment></comment></comment></comment><comment><USER64> 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.

</comment><comment><USER65> 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

</comment><comment><USER66> 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...

<comment><USER16> > 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?

<comment><USER66> 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}'

<comment><USER67> 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.

</comment></comment></comment></comment><comment><USER16> 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)

<comment><USER68> > 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.

<comment><USER16> > 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.

</comment></comment></comment><comment><USER69> 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.

<comment><USER70> Its pretty much a fact of communication that if you can't make yourself understood, you've failed at it.

<comment><USER69> 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.

</comment></comment></comment><comment><USER71> Maybe instead of grinding out code he hates, he should find something he enjoys coding, or maybe don't code at all.

</comment><comment><USER72> 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?

</comment><comment><USER73> 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.

</comment><comment><USER74> Reminds me of the old joke: Knock knock. "Who's there?" ......(pause)......... "Java"

</comment><comment><USER75> 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.

</comment><comment><USER76>
      ...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.

</comment><comment><USER77> 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.

<comment><USER16> ...except he _is_ endorsing it.

<comment><USER21> Maybe he's not "someone reputable"?

</comment></comment></comment><comment><USER78> If java was brainfuck, and we still got the JVM out of it, it would all be worth it.

<comment><USER60> 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

<comment><USER73> #!/bin/cat -

<comment><USER60> Clever. You win one internet.

</comment></comment></comment></comment><comment><USER79> I bet someone is going to post an article named "Why I hate Java"

</comment><comment><USER80> 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.

</comment><comment><USER81> > 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".

</comment><comment><USER82> 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.

</comment><comment><USER83> There's only one way to solve a given problem in Java? Tell that to my AbstractFactoryPoolBean.

<comment><USER84> Don't forget to use Generics.

</comment></comment><comment><USER85> _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.

<comment><USER86> 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?

<comment><USER26> Riiiight. So by that metric, C++ and Smalltalk are OOP either. What exactly _is_ OOP in your world?

<comment><USER86> 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.

</comment></comment></comment></comment><comment><USER87> 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.

</comment><comment><USER88> 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.

</comment><comment><USER89> 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)

<comment><USER90> > 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.

<comment><USER91> 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.

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

<comment><USER93> 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.

</comment></comment></comment></comment></comment><comment><USER94> Why I like it when people are overconfident pompous noobs on the internet

</comment><comment><USER95> 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)

</comment><comment><USER96> 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.

</comment><comment><USER97> It's ironic how this kind of Java bashing comes from a Perl guy.

</comment><comment><USER98> 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.

</comment><comment><USER99> 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).

</comment><comment><USER100> > 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.

</comment><comment><USER84> 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.

</comment><comment><USER101> "What are you? A RAM salesman?"

</comment><comment><USER102> I love this. Keep calm and java on.

</comment><comment><USER103> Is it me (not a native english speaker) or isn't this article all but sarcastic?

</comment><comment><USER104> i certainly wouldn't want this Negative Nancy paying me any compliments ;)

</comment><comment><USER105> 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.

</comment><comment><USER106> 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") }

<comment><USER16> 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?

<comment><USER107> There is no one solution fits all. Especially if the problem is imaginary.

<comment><USER16> > There is no one solution fits all. Especially if the problem is imaginary.

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

<comment><USER107> 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?

<comment><USER16> > 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.

</comment></comment></comment></comment></comment></comment><comment><USER108> Nice article! After reading it I can tell I like Java too.

</comment><comment><USER109> The issue with java is not the language. The language is great.

The issue is the totally over-engineered APIs

</comment><comment><USER110> I like java since I learned it.

</comment><comment><USER111> I really love the JVM. Inversely its related to Java™. I hate it passionately.

</comment><comment><USER107> This post is nerdbait. Not hn material.

</comment><comment><USER112> "cat -" :)

</comment><comment><USER113> what is this, fonts for ants?

<comment><USER114> I feel like I'm taking crazy pills! I invented the piano key necktie! What have you done Derek?!

</comment></comment><comment><USER12> I love Java :)

</comment><comment><USER115> 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.

<comment><USER16> It is pretty much just that... although I think StreamUtils doesn't flush so you'd need to add that.

</comment></comment><comment><USER116> I love Java because when you add 'script' to it you have a pretty sweet language.

<comment><USER117> What, JavaFX Script?

</comment></comment><comment><USER118> Typical ESL Java programmer

</comment><comment><USER110> nice article!

</comment><comment><USER119> Nice article!

<comment><USER110> AGREEEE

<comment><USER119> :)</comment></comment></comment>


The Last of the Hedgehogs: René Girard - <AUTHOR> https://lareviewofbooks.org/article/the-last-of-the-hedgehogs <comment><USER2> I think most people would have heard about him from Peter Thiel. Based on his recommendations I read The Scapegoat last year and it was a real eye opener, with many "mind blown" moments.

For me the really fascinating thought is that the reason the west thrived, was the fact that christianity has an inbuilt awareness about the scapegoat mechanism. Scapegoat being a person who is blamed for all societies ills, who by their martyrdom reduce the tension in a society. Blame all problems on someone, kill them, and suddenly society works better because you've taken the pressure off the pressure cooker.

However, if you understand this mechanism you don't tend to fall into it. Which is exactly what christianity did, the central story in it is literally the killing of a scapegoat. Therefore the west became almost immune to this self created violence.

But this theory in the modern world is completely unacceptable in the mainstream. Anyone who suggests that christianity has any positive side is automatically silenced everywhere. Which is a shame, as he has some really interested theories.

<comment><USER3> > Which is exactly what christianity did, the central story in it is literally > the killing of a scapegoat. Therefore the west became almost immune to this > self created violence.

That's a very nice story that even a casual awareness of the history of the Christian West makes totally implausible.

The Christian West was not immune to scapegoating in much the same way that the sea is not above the sky.

Honestly, you could frame the entire history of the Christian West around _who_ the main scapegoat was at a particular time and place (heck, the Christian understanding of witches/satanists was pretty much an invention almost from whole cloth to fill that role.)

<comment><USER4> > _That 's a very nice story that even a casual awareness of the history of > the Christian West makes totally implausible. The Christian West was not > immune to scapegoating in much the same way that the sea is not above the > sky._

Didn't have to be immune (humans are humans after all, nothing is 100% perfect), just more immune than what preceeded it.

The main idea Christianity added to the table was that the victims are not just unfortunate, or losers, or collatera damage to the natural order of things, but possibly even more justified than those who lord over them.

There were still masters and slaves, injustice, etc despite Christianism, and even in its name, but not _because of_ it.

Similar to like there was injustice and slavery after the Constitution or injustice and racism in the US today, but it's not because of the Constitution itself - which was an improvement and placed a seed for betterment --, but because people are people).

The seed that got into the culture with Christianism was that this is not just "the way things are". Suddenly the victims had a claim to moral superiority and injustice. In the ancient/pagan world they would be laughed off. In the Christian world they might be driven off with sticks still, by those in power, by they couldn't totally eradicate their claim to injustice [that's also why Christianity caught on with oppressed populations, even with those that shared the religion with their opressors, like black slaves in the US or indians in Latin America: it offered a way for the slaves to claim moral superiority and dignity. Incidentally that's how it got its major boost in ancient Roman empire as well].

That's one of the themes of Nietzsche by the way, which he sees as a negative of Christianity (kind of like some lament the modern "victimhood culture") - he preferred the good old times, when masters where masters, and victims would just suck it up and admit defeat and accept that they are lesser men.

(As for the hunt for the "witches/satanists" it's an overplayed minor characteristic of Christianity. Plus, the reason we see those victims too in a favorable light, it's still because of Christian influence. The culture/religion of the group that persecuted them is exactly what promoted them to innocent victims to be pitied/vindicated. The ancient world only cared for effectiveness, victims were merely losers to be tossed aside.

</comment></comment></comment><comment><USER5> Here is a far better written intro to Rene Girard [0], the article linked is worst kind of overwritten academic verbiage with nothing substantive to say, almost incoherent.

[0] [https://alexdanco.com/2019/04/28/secrets-about-people-a- shor...](https://alexdanco.com/2019/04/28/secrets-about-people-a-short-and- dangerous-introduction-to-rene-girard/)

<comment><USER6> Feudalism (and we still have monarchies to this day _cough_ KSA _cough_ ) in tl;dr is the notion that social relations between homo sapiens should be built on the same asymmetric principles as social relations in other large herding domesticated species.

Can we come up with better, more primate, or even more human, systems? I would claim we could, by swapping reflexive antisymmetric transitive relations for reflexive symmetric transitive ones (as those of us with T-V distinguishing languages have largely done), but nearly a half century of people watching has convinced me there exist large numbers of people who are perfectly happy to be servile to some as long as they get to be arrogant to yet others.

</comment></comment><comment><USER7> Girard's idea of _mimetic violence_ , which is the result of people being too similar and not sufficiently different to be considered an un-threatening other, provides both explanatory and predictive power for the culture war as well. When we talk about the uncanny valley in tech, it's a similar visceral reaction. The out-group is us, and yet not us, and is thus an existential threat that makes total war seem inevitable. I didn't read his suggestions for how to unravel that Gordian (Girardian?) Knot, and rather hope he had some prescriptions for avoiding or rolling back points of no return.</comment>


Tusk: an unofficial, open-source Evernote app - <AUTHOR> https://github.com/klauscfhq/tusk#---refined-evernote-desktop-app <comment><USER2> It's an electron wrapper around the official Evernote web app, but with some color themes. Why do I want to use this instead of Evernote's high-performance native desktop client?

<comment><USER3> I have been using it from version v0.5.0, and I can say it is well maintained and user requests are heavily considered when it comes to its development, something not true on how Evernote reacts, when we ask for something. Plus, it is from the dog* who made signale, so it is going to stay of good quality. * Apparently it's not actually that cute dog who made it.

</comment></comment><comment><USER4> Meh… I became so excited seeing the title, thinking it might be some (maybe even self-hosted?) alternative to Evernote. But turns out it's just some "alternative" desktop client for Evernote, not even sure why "on steroids". Well, maybe not today…

<comment><USER5> We've taken the steroids out of the title above.

</comment></comment><comment><USER6> Not a Evernote user, but this looked interesting but for something like Evernote that I would want to have constantly open in the background, another Electron app is just too much of a battery hog.

Another alternative client someone recommended me a while ago is Alternote but never tried it ([0])

At the same time I'm not sure if it's a wise idea to rely on a third-party client for something essential to your workflow as it could get axed at any time. I personally am now with DEVONthink. It's not as sexy looking as this, but immensely powerful once you wrap your head around it

[0]: alternoteapp.com

[1]: [https://www.devontechnologies.com/products/devonthink/overvi...](https://www.devontechnologies.com/products/devonthink/overview.html)

<comment><USER7> Alternote is a pretty good app. I tried it out before. It does use some decent CPU usage too though if I'm remembering right. Nothing close to what an Electron wrapper will give you, but also not what Devonthink will give you. I also have come around to using Devonthink (Mac only).

</comment></comment><comment><USER8> To use the steroids analogy, if you're looking for a sober (minimalist) notes app, checkout Dynalist.io I have most of my life there (lists, plans, journaling, etc) I am not affiliated with Dynalist, just a very happy user

<comment><USER9> Tusk is open source; Dynalist isn't. I just don't get it why anyone would want a subscription to host their private notes online in a proprietary application. Have people forgotten about Microsoft's Word vendor lock-in already?

What you want for your notes is:

0) You need to decide what kind of functionality you need in a note management app which cannot be fullfilled with other alternatives such as a simple text editor (I use Sublime mainly for note taking, plus Google Keep for groceries).

1) An open data format so you are not locked in a platform. This allows you far less time if you want to swap service which decreases monopolistic behavior (vendor lock-in) and increases competition (yay capitalism).

2) You deciding the storage location (this then allows you to use Dropbox or Syncthing or Rsync or whatever cloud, but also allows you to use public-key cryptography such as e.g. Cryptomator). It also allows you to opt-out of the/a cloud.

The logical solution is to use an open source application. Though I'm not sure I'd want it to be a browser (saw NPM in the source tree). I'd say the logical place for this kind of data is near your agenda, like Nextcloud.

<comment><USER10> Tusk might be open source but it's still a client for the proprietary Evernote service, so it's not significantly better according to your criteria.

<comment><USER9> I stand corrected! I thought this was an alternative to Evernote; turns out its just an open source client. This isn't the droid you're looking for. But I'm not sure about the data format of the files. Is that documented?

</comment></comment></comment></comment><comment><USER11> I only scanned through the repo, but surprisingly few lines of code for a app of this size. Good work. Also, should you be using the Evernote logo in the app if it's unaffiliated?

<comment><USER12> Headline is super misleading--it's an electron app that wraps the web interface for Evernote. It's not its own application.

<comment><USER11> That _is_ super misleading. In that case it adds virtually no value over Evernote's own offering (except perhaps eating more battery).

</comment></comment></comment><comment><USER13> I saw the evernote logo in the screenshots and my first thought was "wow, that is a pretty flagrant violation." It wasn't until I read the comments here that I realized it is a wrapper around the official app.

</comment><comment><USER14> Possibly offtopic: Has anyone written any importers / exporters for OneNote?

</comment><comment><USER15> If it's Electron it's the reason to not use it.</comment>


Ask HN: I seem to get colds/flus more often than most people. Suggestions? - <AUTHOR> Okay, I admit it's sometimes because I've stayed up late hacking for a couple of nights in a row. But often not. I seem to have a weaker immune system than many people, and get a fairly bad cold or flu every couple of months.
Anyone else have the same problem? Any ideas for things to do/take/eat to hack your body into getting sick less often? <comment><USER2> Besides diet and sleep, a specific possible factor may be a low or deficient level of Vitamin D. If you suspect yours may be low, e.g. from not enough sun, consider getting your 25-hydroxy levels of Vit D checked. Supplementing with around 2000-5000 IU of Vit D a day could boost your immune system significantly if that is a factor.

Avoid Flu Shots, Take Vitamin D Instead by Donald W. Miller, Jr., MD

<http://www.lewrockwell.com/miller/miller27.html>

Featured Studies: Influenza and Vitamin D

[http://www.vitamindcouncil.org/science/research/vitamin-d- an...](http://www.vitamindcouncil.org/science/research/vitamin-d-and- influenza.shtml)

H1N1 Flu and Vitamin D

[http://www.vitamindcouncil.org/newsletter/h1n1-flu-and- vitam...](http://www.vitamindcouncil.org/newsletter/h1n1-flu-and- vitamin-d.shtml)

</comment><comment><USER3> _Get yourself tested for allergies._ You might have them and not know it. If you've been tested years ago, they might have changed since then (it's normal).

It might start out as a small cold / runny nose, that cascades into sinus infection, chest cold and goes from there. And it can be caused by almost anything - e.g. you might have mold in your house and not know it. It can affect your sleeping and everything else about your life.

Also they're completely treatable by many means (from cheap/less effective to expensive/most effective): 1. avoiding whatever causes the allergy, 2. OTC medicine 3. perscription 4. shots 5. sublingual immunotherapy (slit) <http://allergies.about.com/od/allergyshots/a/slit.htm>

My wife got on the slit therapy and went from having 6 mystery sinus infections a year to now being healthy all the time. It's changed her life.

</comment><comment><USER4> I used to have a very weak immune system, it turned out I was gluten intolerant which was making me exhausted and susceptible to colds/flus. Taking vitamin D and avoiding all grains worked for me.

</comment><comment><USER5> Sleep longer.

[http://www.washingtonpost.com/wp- dyn/content/article/2009/01...](http://www.washingtonpost.com/wp- dyn/content/article/2009/01/12/AR2009011202090.html)

</comment><comment><USER6> I had this problem and solved it with

1\. Sufficient good quality protein in my diet. 2\. Avoiding excessive stress (too much exercise and not enough sleep in my case). Switched to enough sleep so I am awake when the alarm goes off and enough exercise that it makes me feel good not tired. 3\. Take a good quality multi-vitamin and get some sunshine. 4\. Balanced diet - fresh fruit and vegetables.

My days off work sick went from 10/year to <1.

</comment><comment><USER7> How is your general health level? Are you physically fit? Do you take allergy medicines (or anything else that might cause your sinuses to not react normally)?

Are you a smoker? Overweight? A consumer of a poor diet, poor sleeping habits, high-stress, any other poor health practices?

I'd look at your health first, lots of things can make it easier for you to get sick more frequently. If you've moved recently, you may be getting new strains of rhinovirus and flu that your body doesn't know how to fight.

Any way you look at it though, getting sick that frequently tells you that there is something that's just not right. I'd really recommend a visit to your doctor for a checkup / physical. It could be nothing, but it could also be a symptom of some underlying malady.

</comment><comment><USER8> I've had the exact same problem for years and after much fiddling around I too recommend vitamin D3. it's the same as produced by the body from sunlight. eat more fruits and vegetables. maybe take a multivitamin and fish oil daily. exercise regularly. and get enough sleep FOR YOU. some people need more than others.

I don't think it's any surprise that people are much less sick in the summer. People are in the sun much more in summer and hence have higher levels of vitamin D in their blood stream.

I personally feel that sufficient vitamin C and zinc (for men especially) are also important. But taking D3 at 2000-5000 daily is perfectly safe and certainly beneficial.

Why else would your body produce after exposure to UV radiation?

</comment><comment><USER9> Agree with other comments. With regard to zinc, Cold Eeze lozenges or similar. The important points:

There are two zinc compounds involved; some lozenges only have one.

Researchers think that the efficacy of the zinc is largely topical. So, having a lozenge that dissolves slowly -- Cold Eeze are formulated as hard candy -- maximizes efficacy.

You need to start taking the lozenges _at the first sign_ of symptoms. This may be difficult for some. For me, I can usually tell the difference between a cold and something else, like an allergic reaction.

Zinc is a short term boost. You need to look at your overall health, but for avoiding some acute episodes, it can help.

</comment><comment><USER10> I'm not sure this counts as a hack, but try eating a balanced diet, exercising regularly, and getting plenty of sleep. Bonus points for avoiding tobacco and enjoying alcohol only in moderation.

</comment><comment><USER11> Allergies of many kinds lower dramatically the body's first defenses (they make the respiratory tract much easier to penetrate by various bugs). Also most colds and flus, although technically airborne in practice are almost always transmitted by touch. Wash your hands more often and always before eating, and clean the keyboard once in a while.

You may want to look into flu shots. I've heard a lot of opinions pro and against, but if it's a real problem for you then they're probably worth it.

</comment><comment><USER12> Wash your hands after every contact. Vitamin C and Zinc, If you have young children, you are just out of luck.

<comment><AUTHOR> Heh, I do have young children. :-) However, surely there's more to it than that, because plenty of people with young kids get sick less often than I.</comment></comment>


Dynamo - Part I: a followup and re-rebuttals - <AUTHOR> http://jsensarma.com/blog/2009/11/dynamo-part-i-a-followup-and-re-rebuttals/

<comment><USER3> My comment from the blog (currently "awaiting moderation") --

The core misunderstanding here is that Hinted Handoff does NOT mean "ignore W." If it did, clearly R + W > N would mean nothing; in fact, W would be entirely superfluous. So to the degree that the Dynamo paper suggests otherwise, it should be treated as a "bug" in the paper.

So, just to treat your first example, with W=3,R=1 you can't get inconsistent reads since writes will block if any replica is unavailable.

All quorum-based systems that I know of treat R + W like this. For Cassandra, see the code from StorageProxy.insertBlocking, specifically the calls to getNaturalEndpoints, getHintedEndpointMap, and getUnhintedNodes (and QuorumResponseHandler of course). Cassandra is careful to only hint N - <USER2> replicas as I've been discussing.

Everything else you object to basically falls out of this. For example, "there is no way in Dynamo to track how many pending updates have not been reflected globally" — which doesn't matter, since either you are waiting for R + W > N, in which case you get consistency, or you are not, in which case you can't complain if you don't get it. :)</comment>