Hacker News Reader

Comment by xandrius | Hacker News Reader

Not to be snarky but 2011 is yesterday for programming, no major shift. I'd imagine almost all code written there would be able to run today.

View on HN

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 just worked and didn't need any refactoring. (For reference, ClojureScript didn't have a public release until 2011)

For another anecdote, every Golang repository I've found that predates v2 modules is nearly impossible to build, especially if it contains dependencies that link straight to Google Code instead of GitHub. (As an exercise, try building the first public releases of etcd, prometheus, etc. They were super simple projects compared to what they are today, but you will have a tough time building them)

Java and most JVM languages are the rare exception IMO (unless the project uses Gradle). That's one of many reasons why I love working with the Java platform :)

> every TypeScript project I find from 2021 or earlier is simply impossible to build nowadays,

This is the fault of all the bullshit tools that were never any good to begin with (Webpack, Babel, etc) and the Node ecosystem generally causing pain. If you had a package-lock.json you should (in theory) be able to install all of those and it should work. Of course, this relies on dependencies of dependencies actually following semantic versioning but I'm fairly sure many packages on npmjs.org do not follow semantic versioning.

Worst case scenario, you can take your TS files and put them in a newly created project. Preferably the project has a minimal number of build tools, eg, 1. Such as Vite, for example. This effectively replaces easily 5 or 6 major load bearing dependencies that used to be necessary.

Even better: Just use Deno, where it doesn't need any of this to build and run TS files!

How does lock file rely on semantic versioning? It specifies dependencies (and their dependencies) explicitly together with their exact hash

not sure how one can have a problem running something if it installs all the same dependencies and using the same scripts

The JS ecosystem’s churn is unusually bad. I wouldn’t use that as a representative example.

True story, that's why I moved back to Maven (pom.xml) from Gradle.

As a bonus -- IDEs seem to work faster with Maven, I assume because parsing declarative pom.xml is faster than parsing and running imperative build.gradle.

Maven is better than Gradle, full stop. The only real issues with Maven, are the they keep adding features and are bringing in more scripting capabilities. Call me old, but a build system should be purely declarative as a matter of principle. Scripting just leads to someone eventually getting the idea of doing something clever, and then it becomes hell afterwards.

To put it more bluntly, Gradle only matters because of Android.

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.

Exactly, if you have a very old Gradle project, it's best to use the wrapper to keep running with the version of Gradle it was written for, and make sure to use a compatible JDK to compile with (older Gradle versions won't work on new Java versions, which goes against most Java code which will almost certainly run forever even if written for Java 1.1).

Tell me about it... I recently just had the fun of playing with an angular 8 project and thats 'only' 2019. Luckily in that case it was just turning on flags for node to act in an older deprecated way.

For my older projects as long as I could get the right visual studio to install and run (VMs will fix any OS compat issues) I could compile the things out of the box. As we did not go external unless we absolutely had to. These newer central repository projects are not going to end well.

Note that what OP said he found was a JAR, not code. If you found an executable built in any language, I would expect it to still be able to run 13 years later.

JAR is not executable, it's a zip-archived bytecode (basically the same code with better readability for machines, very easy to decompile back to sources, you usually only lose comments and whitespaces). Java is an interpreted language, not compiled, at least mainstream VMs.

The snarky response would be that TypeScript and Go are not industrial strength languages :)

C++, C, even Fortran run just fine after decades.

Nitpick: C++ is not. Far from it. Compiled binary -- yes, but try building a barely old C++ project.

"I have no confidence that a C++ application I built last year with CMake 3.21 will build today with CMake 3.25." (c) https://wordsandbuttons.online/the_real_cpp_killers.html

> For another anecdote, every Golang repository I've found that predates v2 modules is nearly impossible to build, especially if it contains dependencies that link straight to Google Code instead of GitHub

Sorry, but github repo listed above is compiled Java program in jar format. JVM is doing the heavy lifting here. For golang you are talking about building the program. The equivalent of it would running exe or binary format and that definitely would work unless OS/Arch version itself disappeared.

There is ton of churn in Java ecosystem package moving from javax -> jakarta namespace, new date / time/ file libs, build tool, class file format and so on. What could most likely work is standalone jar file running in older and newer JVMs.

> In the Java world, sure.

While 2011 Java certainly still runs today, 2011 Java is Java 6, which probably looks quite a bit different than the Java you'd write today. Not "different language" different, but different enough, especially with lambdas, and if you're doing anything with multithreading, or like to use functional-style streams APIs.

(I remember when generics came out in Java 5... now that did make it look a bit like a different language.)

One would hope so, but in a variety of popular environments that is not the case. Apple is particularly challenging in this regard - keep in mind, PowerPC macs were still actively supported in 2011. Since then we've sunset PowerPC support, sunset 32-bit support, and I imagine we're only a couple of years short of sunsetting Intel support as well

I recently spent upwards of 4 hours trying to get a 2009 python project to run, and the graphical portion is still subtly broken on MacOS...

This is probably the worst case, but I wrote an iPhone game back around then. I recently tried to build it and after a couple of days of not even getting close to something which built (never mind worked when running), I gave up.

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 (Java 10), Records (Java 14), switch and yield (Java 12/14), instanceof (Java 16). Functional programming over OOP; Cloud and microservices, emphasis on security, DevX, concurrency.

Code written in 2011 still runs, but the world's changed around it.

The rise of the web? In the past 13 years? Gosh does that make me feel old...

Shit, I learned to program before there was Google.

I studied OpenGL when all I could find was literally 1 tutorial on it and it was not in my native language.

Reminds of a random comment or tweet I read somewhere where the person said their young children just couldn't believe she was so old that she was born before Google existed :D they just couldn't believe her :D so cute.

I imagine some of us reading this learned to program before bitnet was a thing. Punched cards. Paper tape. Booting by entering a lot of binary numbers with toggle switches. Good times. Oh, and that ancient Fortran code? It still works and, if you can see patterns in arithmetic-if blocks, it still expresses clever algorithms elegantly.

What a world we must have lived in without VSCode, TS and rust, a truly undistinguishable one it seems.

> 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 represented a paradigm shift was lambda expressions (which were released in v8, not v9), the rest are minor features.

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!

There were streams-like libraries before Java 8. It’s lambdas that made them more practical.

concurrency is on your list why? DL added concurrency to Java long before 2011.

I remember using j.u.c in production back when it was still concurrent.jar. There were surprisingly many jobs in NYC/London circa 2006 if you had Core Java skills.

Reply on news.ycombinator.com