You can write a pretty trivial Java program to copy stdin to stdout but Java is <i>still</i> one of the enterprise languages and people writing enterprise applications don't tend to write this type of software (but they do tend to have log4j vulnerabilities). The strengths of Java are its mature dependency management system(s), its comprehensive standard library and the vast ecosystem of third-party libraries. A better test of the language is whether you can write a complicated application in relatively fewer lines of code.<p>I spent much of my career writing Java code but have moved to Go - it's almost a return to my roots as an embedded systems engineer (without the memory management hassles of C) and it's vastly more economical to run Go applications in containers. I do find myself writing code that I used to pull in from a library though.
> Different languages have different failure modes. With Perl, the project might fail because you designed and implemented a pile of shit, but there is a clever workaround for any problem, so you might be able to keep it going long enough to hand it off to someone else, and then when it fails it will be their fault, not yours. With Haskell someone probably should have been fired in the first month for choosing to do it in Haskell.<p>So much unnecessary hate and stereotyping. And I bet they were thinking they're tongue-in-cheek-but-still-sounding-clever.<p>Also, interesting choice of programming languages, neither Python, PHP nor C got any flack, Javascript was spared but Java, Perl and Haskell are evil and using them makes you a "mediocre drone that cares only about cranking the lever and spouting code" (I'm paraphrasing the article here).<p>Choose your technology, learn your tools...<p>> I enjoyed programming in Java, and being relieved of the responsibility for producing a quality product.<p>Although, with that mindset, maybe forego programming altogether.
Java: plentiful well paying jobs, good/great tools, good/great runtime. Personally, I like boring, predictable, "easy" (referring to low cognitive overhead of statically typed languages in general) for work, and save the fun stuff (lisp/scheme in my case) for personal projects.
Yeah, keep writing perl and spout cynicism about everything.<p>I feel like they are chasing a aesthetic of conciseness, their perfect little haskell program, not recognizing that regularity and good api design are much more important.<p>What is beautiful for a 100loc program becomes ugly and wrong for a 100kloc program. Other aspects become much more important.<p>I'm not a huge fan of go, but it proved there is a necessity for boringness in cooperation.<p>Boring syntax does not mean the upper limit is mediocrity, saying that is revealing shallowness.
Five years ago I might have said this was a "dis" or "flame" article. Now I too see the benefits of java while simultaneously feeling it's a bloated and verbose language.<p>We have a tendency to believe that everything we produce needs to be "high quality" but that is a subjective measure. Sometimes we just need to write a program that can be handed off and maintained by the next set of devlopers. For that, java is a useful tool.<p>Programming languages are just tools. You will have your favorite to use but that doesn't mean it's the one you should be using on most jobs.
Obviously the right solution here is:<p><pre><code> #!/bin/bash
cat -
</code></pre>
Java has come a long ways since 2014. You can now code in functional style pretty naturally, checked exceptions are fading from use, and tools like lombok have stripped away the worst boilerplate excesses (getters, equals/hashcode impl).<p>This always riles people up, but I'll assert it again: An <i>equivalent</i> modern app that does something useful is shorter in Java than in Ruby or Python, largely because the type system enforces many of the things you would otherwise have to write explicit tests for.
426 comments when it was originally posted in 2014: <a href="https://news.ycombinator.com/item?id=7463671" rel="nofollow">https://news.ycombinator.com/item?id=7463671</a>
I feel like people get what makes for the best programming language wrong in the same way they get the "fittest" wrong with darwinian selection of "survival of the fittest". It's not necessarily the prettiest (although that can help) or the fastest, or some subjective assessment of the best. It's what survives. Sometimes that's a stallion, other times it's a dung beetle but both are the best at what they do and if you put it in the wrong environment they die. Java's just doing what it does and it has survived where others have died.
> write a program that copies standard input to standard output<p>This is pretty trivial in Java, just as in other languages. But most people don't ever need to learn the low level `System` methods needed to do it.<p>To me, this highlights the difference between a comprehensive approach to learning a language and a more piecemeal one. I learned Java by reading the canonical books from cover to cover, like Effective Java. But I think this is pretty rare.
For example, I recall interviewing many experienced Java programmers who didn't know what things like `protected` or `volatile` mean.
I’ve recently joined a company using Java. I’m open minded, and know that there are lots of good things about the JVM and the modern Java language. However one thing I hate is the complete disregard for command line UX. People writing Java command line tools seem to think it’s absolutely fine to spew 1000 lines of unformatted informational messages and non actionable warnings with bizarre indentation and not to provide any flag to turn this shit off. It’s like they just view the terminal as some sort of obscure log file that no-one’s likely to look at.
These sort of posts crack me up as it's another person jumping on a bandwagon they don't understand, but are also really sad, as it's taking a lot of otherwise talented people and ruining them.<p>> being relieved of the responsibility for producing a quality product<p>I've seen this sort of elitism in candidates and I've made the mistake of hiring them. It turns out they're just not very good at all, and they blame their failures on anything but themselves, stunting their self-growth professionally and interpersonally.
If the infamous HN Dropbox comment didn't exist, this post would serve well as the canonical "facile dismissal".<p>Reminded me of PG's essay about the "blub" programming language.<p>But, in this case, I'd like to reverse the use of the concept: it's not that Java is a blub programming language, but that the OP has only reached a blub-state of understanding it and its potential, and produced a blub (generic and derivative) argument against it.
> If it takes ten times as much code as it would to program in Haskell, that is all right, because the IDE will generate half of it for you, and <i>you are still being paid to write the other half.</i><p>Well that explains it. For me, I’m not going to touch Java unless I’m being paid to do it. IMO it’s a travesty that Java is the language of the AP test, because it really leaves the impression in young people that all of programming is Java. If that were the case, I’d be as far away from programming and computers as I could get.
I've found Kotlin to be a fantastic Java substitute. Fully compatible with Spring and seamless interop with Java.<p>Though I prefer Clojure where that's possible.
I've had a bit of fun with Java some years ago when I was asked to write a converter from some proprietary music format to midi. Using Java was non negotiable requirement. While I succeeded and the project brought me gobbles of cash in very short time I was grinding my teeth on byte / bit level manipulations. Java was definitely not created with this kind of programming in mind.
Modern Java is actually pretty good. It's taken great features from other JVM languages like Kotlin and Scala and is much better for it. The JVM is a wicked fast run time and its nice to have a mature ecosystem of libraries to work from and large pool of developers available who know it inside and out. You could do far worse when picking a language for your team to use.
I actually really don't mind Java-the-language all that much, in fact I'd say I think it's pretty great. My problem with Java is that the ecosystem and culture of Java tend to leaning heavily on annotations for everything. It's not just Spring (though this is probably the worst offender) but everything from Configurations and Command-Line Parsing to DB access and connections, testing, serialization, it seems like overwhelmingly the community leans towards annotations for everything which to me makes working with the tools really difficult to discover and even more difficult to control or modify. There are some exceptions like Vertx.io for instance which are plain-code baed but I find working in a "Java shop" you are usually pushing against the grain if you're trying to avoid Spring/Hibernate/Jackson/etc.
I have written a good deal of Java as a professional Java developer for over 10 years. The core truth the article gets right is that Java is meant to be a language Enterprise developers can use and be reasonably sure other people can pick it up and work with it. Java is a defensible choice in that you can hire people that know Java, easily buy Java training, and have a lot of tools for Enterprise Java development that you can get (OSS or commercial) that will help your Java developers get Enterprise apps created.<p>Java, in many respects, is the COBOL replacement created in the 90s that will live on in the Enterprise for decades to come. Just as COBOL lives on.
Java has a high bar for the amount of prerequisite experience it takes to write good code. In other words, it has too many pitfalls for beginners. It is a phenomenally poor choice of language for teaching beginners to code.<p>On the other hand, a lack of beginner-friendliness could also be seen as a lack of effective static analysis. Of course, this is a very Java programmer point-of-view.<p>Others: "you shouldn't need to have that"<p>Java programmers: "but I do have that"<p>If you are in a position to pick tools for your organisation, think about how your choices would accommodate beginners. Not all of your tools can be or should be easy for beginners to use, but it is an important quality to consider.
A little tongue in cheek, but the strength of Java is that you don't have to actually use it to work in the Java ecosystem. Here is the entire program to copy stdin to stdout in Groovy:<p><pre><code> System.out << System.in</code></pre>
I'm not a professional Java developer, but I work at a company that uses Java, so it just came with the territory to understand things about it, even though I've already had at least a basic grasp of it. I feel blessed that most of the code is mostly straightforward Core Java code (as opposed to any framework-level fun). It is treated a bit like a systems programming language. However, I can agree with this article. It's safely boring to me (despite the fact that having an IDE to write your boilerplate is still necessary for the sake of your fingers.)<p>Since not being a pro at it and not planning to be, I'd rather toy with other things. The job market is diverse in its technical needs. :)
Anytime I learn a new language (I regularly write code in several) I start asking how is testing done, where are the libraries, where is this, and how do I do that? I already have all of that and more at my fingertips. Also, Groovy is vastly underrated. It’s the most economical and easiest to understand language I know meaning I can do more with less code and faster in general.
Yeah, reading it all I still think the author is just dissing Java, despite his, in big bold font "I really like Java". Nevertheless I had a really good laugh.