You can write a pretty trivial Java program to copy stdin to stdout but Java is still 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.
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.
No isNullOrEmptyString method, no Set operations, Java didn't have a good HTTP library until Java 11, no lazy file reading, unless you use InputStream which is a pain.
vast majority of mediocre libraries and one man libraries. We use Spring because it uses the best libraries, so the other ones are discarded.
Java being around for so long doesn't have a lot of convenience methods like others do languages do, like the ones I mentioned in the beginning.
So no, Java is a half assed programming language which C# and NET CORE should replace
Java didn't have all these things, because there were a lot of very good libraries already doing that. Adding them inside a project is trivial. I think this approached encouraged creating alternatives to the standard APIs as well as extensions which in the end made the language even more rich.
At last workplace we developed microservices running on Kubernetes using Redis and Postgres as databases. Integration with Elastic Search, Kibana, Datadog were a breeze.
I'm really not sure I would call Java's standard library comprehensive. I've only worked with it for a few months but needed many Apache commons libraries.
By the standards of the day, when Java was released it's standard library was pretty comprehensive: in addition to covering most of the c-ish stdlib, it had networking and web-aware apis.
It did set a new standard in a way that was very beneficial for the languages that came after it: you're not an ACTUAL language if you don't have a "good" standard library, and I can argue that "good" was defined by Java more than C++ or anything else at the time.
I also don't see any new languages, while more modernized, that have substantially pushed the envelope further to be the new gold standard of a minimum batteries included stdlib. All I could probably say is various threading/concurrency apis, but Java has added a lot of that too over the years.
Which falls under the heading of "mature dependency management system". Apache Commons (or Google Guava) is pretty much considered part of the standard library at this point, as they are so easy to include in projects.
The domain and the developers that inhabit that domain should be separated from the language. Below is the repo of the companion Java code to Sedgewick's "Algorithms" - make of it what you will.
On the right side of the page, you can find eleven (!) different wants to include this dependency (and) all of its transitive dependencies with just a few lines of configuration.
>People say this but where do you find libs for Java?
Everywhere, on the lib website, on GitHub, on Apache, etc. (including centralized places like Maven Central). You then put a ferences in your Maven or Gradle file like you would in your package.json.
In fact, because for 99% of the libraries you just need to have a jar (or more) in your classpath, you don't have to have all the ceremony that Python has, and all the installation mess, venvs, and other such shite.
If this isn't a joke, I'd suggest learning the Maven or Gradle build systems. NPM has such horrible dependency management that these Java systems will seem like magic!
The Java ecosystem of libraries is huge, it used to be one of the largest ones. I don't know how it competes today with Python and JS, but Java certainly doesn't lack libraries for almost anything you can think of.
Err ... the npm authors (the CommonJS modules/packages spec writers for package.json) mention maven and CPAN in their design docs and discussions as reference. Many of the early Server-side JavaScript adopters (in the 2000's before Node.js but well after Netscape's server-side JavaScript) were, in fact, Java/J2EE dropouts longing for something simpler.
One of the nice things about Java and C# is that they tend to have "chunkier" dependencies, that aren't split out into an interlocking tree of dependencies deep and wide.
For the most part, anyway... Things are kind of gross if you are trying to use newer nuget packages on the old 4.8 .net framework...
In Java-land most people build and do dependency management with Maven or Gradle. In either case, these tools can pull from repositories based on the Maven format. The vast majority of popular libraries are in repo "Maven Central" and "just work" if added to your dependency list. A number of smaller, more specialized repos also exist, and it's trivial to add additional repos to your Maven/Gradle config as well.
You can search for libraries on mvnrepository.com, or your IDE can search the index. Also most libraries will include a section in the documentation that shows the details of the blob you have to put in your pom.xml / build.gradle file.
> 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.
So much unnecessary hate and stereotyping. And I bet they were thinking they're tongue-in-cheek-but-still-sounding-clever.
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).
Choose your technology, learn your tools...
> I enjoyed programming in Java, and being relieved of the responsibility for producing a quality product.
Although, with that mindset, maybe forego programming altogether.
The author makes it really hard to judge his tone, but I don't think you're reading it right. For example, if you peruse his other articles, it's clear he really likes Haskell (he certainly doesn't consider it evil).
I can't say I understand every one of his assertions, and trying to be funny/sarcastic makes it hard to truly understand the point of his article, which I think is: Java lacks focus and is a verbose language, and therefore you should probably pick something else to solve interview challenges. I tend to agree.
I thought he summed up the tone pretty well earlier in the article:
> Java is neither a good nor a bad language. It is a mediocre language, and there is no struggle.
To be more explicit - I think the point he is trying to make is that Java is not very powerful (in sense of expression), which has benefits (making it hard to fuck up badly) but at the cost of pushing the programmer towards mediocre, verbose and inefficient solutions (again due to lack of expressiveness, trying to come up with elegant and efficient solutions is too tiresome).
Perhaps it's the difference between a scalpel and a blunt club. You're not going to cut off your own fingers with the club, but you're not going to be able to perform brain surgery or fix someone's heart either. Not the best analogy because technically Java and any other language is turing complete, but they are not equal in how easy it is to coerce the machine into performing a particular computation, and expressing that humanly.
The author is MJD. He is, among other things, the author of one of the best functional programming books[1].
> I was a professional Java programmer for three years (in a different organization), and I have meant for some time to write up my thoughts about it. I am often very bitter and sarcastic, and I willingly admit that I am relentlessly negative and disagreeable, so it can be hard to tell when I am in earnest about liking something. I once tried to write a complimentary article about Blosxom, which has generated my blog since 2006, and I completely failed; people thought I was being critical, and I had to write a followup article to clarify, and people still thought I was dissing Blosxom. Because this article about Java might be confused with sarcastic criticism, I must state clearly that everything in this article about Java is in earnest, and should be taken at face value. Including:
> I really like Java
> ...
> So yes, I enjoyed programming in Java, and being relieved of the responsibility for producing a quality product. 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. The code was ridiculously verbose, of course, but that was not my fault. It was all out of my hands.
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.
This is how I feel about C# and .Net - they are relatively easy to hold in your head, the tools are excellent for the language, and there are plenty of decent paying jobs.
There is very little to trip you up in C#, for my first project in it I sat down and started churning out code and looking stuff up when I got stuck. Try doing that with C++ and you will end up with a hole lot of trouble.
Yeah, keep writing perl and spout cynicism about everything.
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.
What is beautiful for a 100loc program becomes ugly and wrong for a 100kloc program. Other aspects become much more important.
I'm not a huge fan of go, but it proved there is a necessity for boringness in cooperation.
Boring syntax does not mean the upper limit is mediocrity, saying that is revealing shallowness.
The notion that languages focused on writing large-scale programs must be "boring" seems a bit silly. What these languages need is lots of ways to define sensible modularity boundaries, and the "boring" aesthetic (or lack thereof, rather) can really get in the way of that.
Boring Is Best! When you have junior programmers joining/leaving teams, consistent, boring code written in one Boring PL according to Boring Code Conventions is like driving on a freeway in one straight direction with auto-pilot on.
Clever code written in half-a-dozen Cool PL's is like driving for your life in sharply turning mountain roads with no guard-rails - something guaranteed to become cataclysmic as your number of issues/escalations rise and rise, your tech debt becomes an un-surmountable mountain and you watch your hair turn grey before you are middle-aged.
I would submit that any language that reaches the level of adoption that Java does will be considered boring. The human mind has a tendency to prefer new/fresh things, particularly for people high in trait openness (big 5 personality traits).
> What these languages need is lots of ways to define sensible modularity boundarie
One of the most important modularity boundaries is dependencies on libraries written by others. So a good, easy to use dependency manager and a straight forward mechanism for creating and sharing libraries is crucial.
TL/DR: it's about readability and clarity of unfamiliar code.
One problem of large codebases is that they tend to be team efforts. Given a a sufficiently large and flexible language, each team member will find their own style and idioms for their code. This creates the subtle problem that team members are unfamiliar with each other's styles and when they touch the same pieces of code, they each extend the subset of used language features by whatever is required for their favorite idioms. Eventually, the resulting code gets too elaborate for its own good and maintainability goes down. A boring, simplified language ideally constrains the team to use more or less the same patterns and idioms and this side-steps the problem.
Can I say one thing that is great about the JAR ecosystem -- at least in a safe "closed moat" enterprise setting? Monkey patching buggy JARs! In my experience (and many others!), it is pretty common to manage an enterprise Java project that is stuck on an ancient version of a JAR. (This can be true in any language.) If you find a bug, it might be too hard to upgrade to the latest version. But you can easily copy the source code into your project and monkey patch it. Yeah, it won't win any awards, but it keep the ball of mud rolling forward. Yes, I know this technique can be used in lots of other languages.
Also, you make it sound like Java -- in particular -- has a lot of poor open source libraries. I would say the same for Perl. I wrote it for many years, and I was constantly working around tiny bugs in open source libraries. This isn't a comment on Perl or people who contribute to open source Perl libraries. Rather, this is the reality of using a huge amount open source libraries. About 98 to 99% will be "good enough". Then, you need to hack around the last 1-2% buggy bits.
One thing I have noticed in general (JavaScript, Python, DotNet, Java, C++), in the last 10 years, there has been a dramatic rise in unit tests in open source libraries. Fifteen years ago, you were lucky to have any unit tests. Some of the best libraries now advertise their unit test code coverage on GitHub. It is great progress.
I'm just happy if I can sort of read the code. My standards are pretty low for judging existing code bases. This is not to say I'm not going to mouth a long drawn out WTF several times a day or scream "dogshit!" at the screen sometimes.
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.
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.
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.
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).
This always riles people up, but I'll assert it again: An equivalent 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.
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.
Readit News
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.
To a point. In many situations, a better test is whether a coder unfamiliar with said complicated application can maintain it relatively easily.
vast majority of mediocre libraries and one man libraries. We use Spring because it uses the best libraries, so the other ones are discarded.
Java being around for so long doesn't have a lot of convenience methods like others do languages do, like the ones I mentioned in the beginning.
So no, Java is a half assed programming language which C# and NET CORE should replace
Im not saying C# is bad as I don‘t have experience with it, just that Kotlin is a more realistic replacement for most Java shops.
I am happy to try different languages but I will never again support a Windows Server over a Linux VM.
So many other abandoned programs seem to become unbuildable pretty quickly.
It did set a new standard in a way that was very beneficial for the languages that came after it: you're not an ACTUAL language if you don't have a "good" standard library, and I can argue that "good" was defined by Java more than C++ or anything else at the time.
I also don't see any new languages, while more modernized, that have substantially pushed the envelope further to be the new gold standard of a minimum batteries included stdlib. All I could probably say is various threading/concurrency apis, but Java has added a lot of that too over the years.
https://github.com/kevin-wayne/algs4/tree/master/src/main/ja...
Python has pip,
JS/Node has NPM
Here is an example library from Google called "Guava": https://search.maven.org/artifact/com.google.guava/guava/31....
You can find the source code on GitHub: https://github.com/google/guava
On the right side of the page, you can find eleven (!) different wants to include this dependency (and) all of its transitive dependencies with just a few lines of configuration.
Here is a list of the Top 10 downloads of open source Java libraries: https://mvnrepository.com/popular?p=1
Everywhere, on the lib website, on GitHub, on Apache, etc. (including centralized places like Maven Central). You then put a ferences in your Maven or Gradle file like you would in your package.json.
In fact, because for 99% of the libraries you just need to have a jar (or more) in your classpath, you don't have to have all the ceremony that Python has, and all the installation mess, venvs, and other such shite.
If this isn't a joke, I'd suggest learning the Maven or Gradle build systems. NPM has such horrible dependency management that these Java systems will seem like magic!
Also: Maven Central.
[1]: http://wiki.commonjs.org/wiki/Packages/1.0
For the most part, anyway... Things are kind of gross if you are trying to use newer nuget packages on the old 4.8 .net framework...
You can search for libraries on mvnrepository.com, or your IDE can search the index. Also most libraries will include a section in the documentation that shows the details of the blob you have to put in your pom.xml / build.gradle file.
So much unnecessary hate and stereotyping. And I bet they were thinking they're tongue-in-cheek-but-still-sounding-clever.
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).
Choose your technology, learn your tools...
> I enjoyed programming in Java, and being relieved of the responsibility for producing a quality product.
Although, with that mindset, maybe forego programming altogether.
I can't say I understand every one of his assertions, and trying to be funny/sarcastic makes it hard to truly understand the point of his article, which I think is: Java lacks focus and is a verbose language, and therefore you should probably pick something else to solve interview challenges. I tend to agree.
> Java is neither a good nor a bad language. It is a mediocre language, and there is no struggle.
To be more explicit - I think the point he is trying to make is that Java is not very powerful (in sense of expression), which has benefits (making it hard to fuck up badly) but at the cost of pushing the programmer towards mediocre, verbose and inefficient solutions (again due to lack of expressiveness, trying to come up with elegant and efficient solutions is too tiresome).
Perhaps it's the difference between a scalpel and a blunt club. You're not going to cut off your own fingers with the club, but you're not going to be able to perform brain surgery or fix someone's heart either. Not the best analogy because technically Java and any other language is turing complete, but they are not equal in how easy it is to coerce the machine into performing a particular computation, and expressing that humanly.
> I was a professional Java programmer for three years (in a different organization), and I have meant for some time to write up my thoughts about it. I am often very bitter and sarcastic, and I willingly admit that I am relentlessly negative and disagreeable, so it can be hard to tell when I am in earnest about liking something. I once tried to write a complimentary article about Blosxom, which has generated my blog since 2006, and I completely failed; people thought I was being critical, and I had to write a followup article to clarify, and people still thought I was dissing Blosxom. Because this article about Java might be confused with sarcastic criticism, I must state clearly that everything in this article about Java is in earnest, and should be taken at face value. Including:
> I really like Java
> ...
> So yes, I enjoyed programming in Java, and being relieved of the responsibility for producing a quality product. 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. The code was ridiculously verbose, of course, but that was not my fault. It was all out of my hands.
[1]: https://hop.perl.plover.com/
He says that about Java alone. He very clearly says it doesn't apply to Perl or Haskell.
Also, there is no judgement on the coder, he states that anybody, good or bad, caring or uncaring creates mediocre code on it.
And, well, it fits my experience.
Deleted Comment
Good overview here: https://advancedweb.hu/new-language-features-since-java-8-to...
And many other changes in the pipeline too..
Dead Comment
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.
What is beautiful for a 100loc program becomes ugly and wrong for a 100kloc program. Other aspects become much more important.
I'm not a huge fan of go, but it proved there is a necessity for boringness in cooperation.
Boring syntax does not mean the upper limit is mediocrity, saying that is revealing shallowness.
Clever code written in half-a-dozen Cool PL's is like driving for your life in sharply turning mountain roads with no guard-rails - something guaranteed to become cataclysmic as your number of issues/escalations rise and rise, your tech debt becomes an un-surmountable mountain and you watch your hair turn grey before you are middle-aged.
One of the most important modularity boundaries is dependencies on libraries written by others. So a good, easy to use dependency manager and a straight forward mechanism for creating and sharing libraries is crucial.
Java does really well in this regard.
One problem of large codebases is that they tend to be team efforts. Given a a sufficiently large and flexible language, each team member will find their own style and idioms for their code. This creates the subtle problem that team members are unfamiliar with each other's styles and when they touch the same pieces of code, they each extend the subset of used language features by whatever is required for their favorite idioms. Eventually, the resulting code gets too elaborate for its own good and maintainability goes down. A boring, simplified language ideally constrains the team to use more or less the same patterns and idioms and this side-steps the problem.
Do note these are more than a little flaky with many of the Java libs out there ;)
There's a bit of everything, good quality and poor Java code. It's just that there is so much of it out there, that a lot tends to be crud.
Also, you make it sound like Java -- in particular -- has a lot of poor open source libraries. I would say the same for Perl. I wrote it for many years, and I was constantly working around tiny bugs in open source libraries. This isn't a comment on Perl or people who contribute to open source Perl libraries. Rather, this is the reality of using a huge amount open source libraries. About 98 to 99% will be "good enough". Then, you need to hack around the last 1-2% buggy bits.
One thing I have noticed in general (JavaScript, Python, DotNet, Java, C++), in the last 10 years, there has been a dramatic rise in unit tests in open source libraries. Fifteen years ago, you were lucky to have any unit tests. Some of the best libraries now advertise their unit test code coverage on GitHub. It is great progress.
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.
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.
https://en.wikipedia.org/wiki/Worse_is_better
This always riles people up, but I'll assert it again: An equivalent 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.