Live data from Hacker News

I found one of my first programs (Java, 2011) on the Wayback Machine and it runs

github.com

121–130 of 193 posts

Re: I found one of my first programs (Java, 2011) on the Wayback Machine and it runs

#121

Earlier quoted context omitted.

Java's maintained almost perfect backward compatibility. If you want code you wrote today to run in 10 more years, Java is probably the best choice. Most other languages have too much of a history of breaking changes, or if you pick C/C++, you'll have issues linking against an old UI library.

There are many other languages with a better lindy effect rating ( https://en.wikipedia.org/wiki/Lindy_effect ), common lisp, erlang, fortran and more. I won't doubt how java doing well, but other languages have it beat.

Yeah have you tried actually running a common lisp program from decades ago on a different implementation from the one it was developed on?

Re: I found one of my first programs (Java, 2011) on the Wayback Machine and it runs

#123
post #79

Earlier quoted context omitted.

In the Java world, sure. Other programming language ecosystems tend to have tons of churn. For an anecdote, every TypeScript project I find from 2021 or earlier is simply impossible to build nowadays, meanwhile the ClojureScript code I dealt with in a previous job was able to survive 8 years worth of updates to libraries and the core language. I frequently ran into code that was last modified around 2013 because it j…

What you say about Gradle's instability over a long time is so true. Even code snippets from 3 to 5 five years ago seldom work without some (more or less random) adjustments.

It's been standard practice for a very long time to use the Gradle wrapper, which fixes the Gradle version, so there really shouldn't be a problem building an old project.

Making changes to one is indeed fraught.

Re: I found one of my first programs (Java, 2011) on the Wayback Machine and it runs

#124

Earlier quoted context omitted.

You've had a very different experience of the past 13 years if you've experienced no major shifts. Even the past year has had a whole big change with the advent of LLMs, nevermind the rise of the web, VSCode, typescript, rust, and more. In 2011, Java was on version 7. We're on 22 now in 2024. There have been some paradigm shifts in Java during that time. Streams (Java 8), Lambda expressions (Java 9), the var keyword…

> In 2011, Java was on version 7. We're on 22 now in 2024. In the IDE technology, the jump was even larger. In 2011, I was using Intellij 10, now I'm on version 2024. > There have been some paradigm shifts in Java during that time. Streams (Java 8), Lambda expressions (Java 9), the var keyword (Java 10), Records (Java 14), switch and yield (Java 12/14), instanceof (Java 16). The only listed Java feature which represe…

Streams had a pretty huge impact on how a lot of people write code.

Also, lambdas came in in 8, not 9. Streams without lambdas would have been pretty painful!

Re: I found one of my first programs (Java, 2011) on the Wayback Machine and it runs

#125
post #33

What a strong ad for Java

Seriously. Remember applets? My first real Java app was a small 3D Pong game using AWT, and it still works using appletviewer on my M1 MacBook Pro. I mean, it's circa 1998.

I found an old applet of mine from the late '90s, and tried running it. Crashed with a NullPointerException from deep inside AWT. My guess is that there is now some setup that needs to be done that didn't at the time.

Re: I found one of my first programs (Java, 2011) on the Wayback Machine and it runs

#126

I promise you that there are major businesses still running on Java 6 code from 2011.

As a dark matter architect, I can tell you: You do not need to promise. That is reality ;). You let the system run some years successfully, never touch a running system, than you fire fire-everyone involved cycle, then do something important, maybe plan the successor system and but then scrap that. And then budget is tight and the UX needs it more urgent. 2024 it is.

Re: I found one of my first programs (Java, 2011) on the Wayback Machine and it runs

#128

Earlier quoted context omitted.

2011 for Java is nothing. I've used JDBC driver written for Java 1.4 (2002) in Java 17 and I absolutely sure that it'll work with Java 21 just as well. Java backwards compatibility is real and it works absolutely fine unless you do bad things.

I think the last breaking change I remember was enumerations being added, which broke any code that used the class name as a variable name. But I could be wrong; it was almost 20 years ago.

Maybe not a part of language per se but they throw out corba in java 11 and this decimated some very old libraries that used is as dependency.

Re: I found one of my first programs (Java, 2011) on the Wayback Machine and it runs

#129
post #43

Earlier quoted context omitted.

that should be the norm. the reality is that is a strong ad against almost all modern frameworks, that may live for as little as a football season

Not really. Not automatically, anyway. Realistically, code lasting forever is, the majority of the time, some engineer’s nerdy wet dream almost completely devoid from any real-world requirements. “This code should last 20 years” should, for most people, be fairly low on the list of desires for a technology stack. In the vast majority of cases, the processes that the software seeks to automate will have been thrown ou…

>> But let’s not kid ourselves that the stuff we’re writing is even intended to last a long time.

Not my experience at all. I am literally at this moment releasing new version of private app framework that was created by few people (including me) about 18 year ago for few clients on long forgotten platform because some client (who is still paying support fees!) found some obscure bug building new application using this framework. The previous version was released about 8 years ago.

Re: I found one of my first programs (Java, 2011) on the Wayback Machine and it runs

#130
post #123

Earlier quoted context omitted.

What you say about Gradle's instability over a long time is so true. Even code snippets from 3 to 5 five years ago seldom work without some (more or less random) adjustments.

It's been standard practice for a very long time to use the Gradle wrapper, which fixes the Gradle version, so there really shouldn't be a problem building an old project. Making changes to one is indeed fraught.

You're right that including the Gradle wrapper is a common good practice for years. But if you have to or want to move to a newer Gradle version than you can enjoy the full randomness of the domain specific language from Gradle itself and from a thousand plug-ins.
Post reply on HN