Hacker News Reader

Comment by habosa | Hacker News Reader

I haven't been coding as long as most (about 10 years) but I've had phases of Java, Ruby, Python, JS, TS, ObjC, etc.

If I go onto my GitHub and try to get any of my old projects running I am extremely confident that the non-Android Java ones will still work. All of the other ones will probably have "rotted" over the years and send me down a day-long rabbit hole looking for old dependencies or build systems.

There's something to be said for that amazing stability. I can't think of another language where you can find some .edu page from 2001 with a link to a library (.jar) that does what you need and you can actually use it in a modern application.

View on HN

This, so much this. The value of code just working and staying working is humongous. Having code that is unchanged from Java 1.3 doing it's thing and delivering value 21 years later without needing to be touched and revisited allows us to focus on improving the code that needs to be improved.

Doesn't mean we don't touch old code (change idioms, generic safe, build process etc). It means we do it when there is value to us for updating it. Not because we are forced to due to an infra change.

At the same time code that ran on a PA-RISC machine now happily runs on a mac arm (even then it was great because the same code ran on PA-RISC, powerpc, x86 and X86-64).

If that code was written in python it would have likely gone through two breaking cycles at least. C sure that would have worked but the cost of having it working such a variety of systems would have been humongous for a small group like us. What real alternatives have this claim? C++ chances that I can compile code from 2000 without issues is minuscule.

Sure I had my EJB "fun", and when I look at some of the micro-services being deployed I see the same problems. Because they are reflections of organizations. (i.e. sometimes have the feeling that changing language in an org is like switching your in-office communication to Italian, because it so fast and romantic.).

Just because there was "bad" code written in the past doesn't mean new code is done that way. Yes it exists, yes it needs to be poked once in a while, but that is a lot cheaper than rewriting in a modern style.

> C++ chances that I can compile code from 2000 without issues is minuscule.

Really? I have code from the late 90ies and it compiles just fine. Do you perhaps mean dependencies? Because the issue there is the completeness of the framework and libraries around Java rather than the language itself.

Yes, the C++ dependencies are unlikely to be available. Specifically dependencies on OS libraries that are just not available on current common systems.

So you need to get them but they are not available anymore and may depend on code that doesn't compile anymore. Due to e.g. 32bit assumptions, changes in what a 'long long' means and small hiccups like that.

Or the fact that C++ code was "almost" C++ code and not actually C++ code. Just a variant that was supported by an "almost" C++ compiler.

Not really the case for smaller utilities but larger projects originating on what is now rare equipment suffered from this.

So maybe not "miniscule" but not rare in my experience either.

> Specifically dependencies on OS libraries that are just not available on current common systems.

But again, that's a problem with the OS, not a problem with C++. POSIX compliant code still compiles just fine on POSIX-compliant platforms and 32-bit code compiles just fine with 32-bit compilers as well - nothing changed in that regard. It's a similar story with other APIs such as Win32.

> Due to e.g. 32bit assumptions, changes in what a 'long long' means and small hiccups like that.

If you try to compile 32-bit code as 64-bit code you're porting, not recompiling. You can also just specify -std=c++98 (with g++) or just use an old compiler.

In my experience the problems with Java code are just as annoying, but those problems don't come from within the language itself either.

Things that weren't natively available had to be added via external scripts, application servers, native libraries, etc. And getting a fragile jumbled mess to work that relied on a specific Tomcat server version, command line scripts, external libraries or - god forbid! - certificates, was a major PITA as well.

Even today trying to get something as simple as SSL certificates working with Java can be frustrating. Why? Because for some reason Java insists on keeping its own keystore because it's the JDK that decides which authorities are to be trusted - not the user, not the OS, only the JDK.

Well, one of the installed versions, which gets to be real fun if you're working with containers, but I digress...

All very fair points. But I think the ecosystem of a language is part of this discussion. And the ecosystem of year 2000 C++ is hard to run on current systems. While the ecosystem of year 2000 java still works.(IMHO better than 2005 java)

I would definitely not say that java is perfect, but the java ecosystem does have some very practical advantages that more than compensate for some of its very real disadvantages.

I've been mainly a Java developer for almost 15 years, but was working with Python the last few months.

I LMAO when Python changed (or broke...depending how you look at it) the basic print functionality between version 2 and 3. Meanwhile I can use the latest and greatest JDK to compile old java code.

Don't get me wrong, I think Python is awesome for what I needed to do (data manipulation) and would likely be my language of choice for such tasks in the future.

Also, the best way to get a highly commented article on HN is to write one on why you love, or hate Java.

My experience with C# is similar. It was always designed to be a Java clone, and Microsoft is well-known for their backwards compatibility.

I once wrote an application in 2005 that kept running with unmodified source code up until 2017 in production across multiple operating system upgrades, database upgrades, and a transition from 32-bit to 64-bit runtimes.

And then they decided to end that line of succession. .NET Framework 4.8 is the last version of the framework. I've started experimenting with converting code to .NET 5, but it's a rather large jump compared to any previous upgrade. Going from 2.0 to 4.0 had a few minor hiccups, but going to .NET 5 is basically a rewrite of the framework and runtime, and I'm not sure how old and new assemblies will co-exist. It feels like a fragmenting of the ecosystem, where a bunch of code will be stuck on .NET 4 forever, and other code will move to the .NET 5 and later.

I'm almost expecting a few years down the road, Microsoft will go back on 4.8 being end-of-the-line for .NET 4 and start releasing new minor versions of it because of all the customer code that can't be ported to .NET 5. Or maybe it will just end up like VB6. Stuff written in it still works, and will continue to work, but it's considered a dead language.

"[C#] was always designed to be a Java clone"

"Initially" would be somewhat closer to the truth than "always".

It's still pretty damn similar and they continually add new features to match the other, keeping up with the joneses.

It's mostly Java that's playing catch-up, so arguably it's Java "cloning" C# rather than the other way round, and it's been that way for years now.

This, absolutely. I don't think any of my javascript, python projects, or even golang (pre-modules) would even build after a clean checkout. My maven projects? Sure they will build, and the tests will run just like the last time. Java is not exciting, it's just fine. I really don't get the level of hate Java gets in certain circles. It's like people are putting their entire identity on the line based on their currently preferred programming language.

Reply on news.ycombinator.com