6 ms·

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

by jerven 5y ago

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.

qayxc 5y ago
> 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.
- jerven 5y ago
  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.
  - qayxc 5y ago
    > 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...
    - jerven 5y ago
      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.
fma 5y ago
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.

by jerven 5y ago

qayxc 5y ago

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

jerven 5y ago
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.
- qayxc 5y ago
  > 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...
  - jerven 5y ago
    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.

fma 5y ago

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.