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.
Why I Like Java (2014)
51–60 of 152 posts
Re: Why I Like Java (2014)
#52Earlier quoted context omitted.
Correct, but it’s worth noting that ‘volatile’ in Java does provide atomicity.
True, the guarantee of atomicity does come up in Java wrt. fields of type long or double, for which atomicity is not provided by the Java memory model in the absence of volatile. More to the point, volatile in Java provides linearizability which is a bit stronger than simple atomicity.
*sequential consistency, not linerarizability
Re: Why I Like Java (2014)
#53You 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…
People say this but where do you find libs for Java? Python has pip, JS/Node has NPM
To compliment most other posters, they would use Maven Central: https://search.maven.org/
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
Re: Why I Like Java (2014)
#54> 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…
> mediocre drone that cares only about cranking the lever and spouting code
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.
Re: Why I Like Java (2014)
#55tangent: what are some modern java OSS codebases that you would recommend to read?
I found the server code of the Signal messenger to be very readable https://github.com/signalapp/Signal-Server
Re: Why I Like Java (2014)
#56> write a program that copies standard input to standard output 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. 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.…
Volatile is an interesting one because it highlights a facility of the JVM that some other runtimes don't provide, namely multi-threading AND multi-process. Someone coming from node or python for example may not appreciate what's going on behind the scenes unless they go looking or have been exposed to those ideas.
Re: Why I Like Java (2014)
#57Yeah, 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…
> regularity and good api design are much more important 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.
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.
Re: Why I Like Java (2014)
#58> 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…
> mediocre drone that cares only about cranking the lever and spouting code 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.
his description of perl is even less charitable
Re: Why I Like Java (2014)
#59Earlier quoted context omitted.
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.
The point being that at scale all code should be written the same way, in an environment where most teams are composed of rotating consultants.
Well, the counterpoint is that you shouldn't have a team composed of rotating consultants. And if you have one, you can't expect it to deliver anything with any quality or productivity.
But yes, if that's your team, then all code should be written the same way, all on the most boring way possible.
There's a reason Java and C# are so popular.
Re: Why I Like Java (2014)
#60If the infamous HN Dropbox comment didn't exist, this post would serve well as the canonical "facile dismissal". Reminded me of PG's essay about the "blub" programming language. 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…
If people are unfamiliar with the "blub" programming language, you can read more here: https://wiki.c2.com/?BlubParadox
Here is Paul Graham's original essay: http://www.paulgraham.com/avg.html
To quote Wiki (https://en.wikipedia.org/wiki/Paul_Graham_(programmer)): >
In my experience, it sounds like a very cool idea, until the first time you see someone programming DirectX using Excel/VBA. (Yes, it can be done.) My point: When you see someone using a "dumb" language (in your humble view), first ask if you are ignoring a Chesterson's Fence! For the avoidance of doubt, no, I am not seriously suggesting it is a good idea to program DirectX using Excel/VBA in 2022.