I was only allowed to use perl 4 to write this software and I wasn't allowed to use a database, even though the datastructure for a day's publishing batch had tens of thousands of keys and values and required RDBMs style queries. It also features a configurable postscript parser that extracts all kinds of data from completed newspaper pages that informs the publishing system. When I wrote it I was told that it would run for a few months only while we figured out how to get a $5M commercial product to handle the work.
The whole thing was written in perl 4 style OO Perl and came in at about 16k lines of code in the end -- most of the code was for the postscript processor and tons of cruft that I had to write to made a relational DBMS in memory because I wasn't allowed to use mysql. It took me four months to write it. I launched it in January of 2002 and it runs to this day. I know this because I got a call about it last month where my replacement's replacement's replacement asked me a few questions about what OO Perl is because he wanted to make a few changes. Good luck! It still runs and is responsbile for about 80% of what it was originally built to do. It is used by hundreds of people daily, who by all reports absolutely hate it. There are people working at the newspaper today that use it regularly that were not born when I wrote it. I am twice as old as I was when I wrote it.
They have apparently tried to replace it several times over the last 22 years and have failed to do so... this is likely due to the blockheadedness of my old boss (who is still there) as much as the radically insane obscurity of my code, which is exactly how you'd expect 16k lines of 22 year old OO Perl 4 would be.
I created a database publishing platform exactly that time, a was given full control. I created it in Java, and added a JavaScript engine for scripting templates. The initial product was also side in a few months. It also runs to this day. The war file could be run by any Java server. The code, while old, was in a reasonable state, given some of the migrations.
I never thought about the code being older than the people working on it
The idea is to split messages in chunks and sort the rows by ISIN instead of having one big file without any sorting pattern, and it cuts the processing by the app from a few hours to 10 min. Never heard of a bug in this one but it's only like 300 lines of code.
(perl 4 didn't have built in support for OO; did you roll your own system?)
Not sure who else recalls it? Really appreciated the monthly format as well, I think summarising the last month and going in-depth on specific stories ended up being a good touchstone for what happened in the community.
If anyone is interested in picking up the torch, I for one would be happy to resubscribe to it :)...
Well that's pretty impressive. Most of my garbage pearl code from 20 years ago would probably look like line noise to most modern developers if it wasn't for the shebang.
Whenever i see terse C or load bearing perl it does look like line noise.
What does that mean? Perl's basic OO support (using blessed hash references) was introduced with Perl 5 in 1994. I have no idea how anyone would even attempt writing OO code in Perl 4.
This made me chuckle because as a software development intern in 1988 (being paid like $8 an hour) I wrote a giant monstrosity of a time tracking program for a local CAD company in an Empress database using its forms builder interface. It was in use for far longer than anyone ever intended and whenever I ran into someone from that company years later they would tell me how bad it was. Sorry guys!
Old pictures I never thought I’d ever see again. Landing pages for old companies I’ve built and only a handful of my closest friends remember. Blog posts from long deleted places, times, and mental caverns.
Just incredible.
Like yourself, I think it's an incredible resource and don't mind pitching in( when I can) to help keep it running.
1: https://archive.org/details/alexacrawls?sort=-downloads&and%...
This project came to mind recently and I looked around on the Wayback Machine. Turns out I posted the jar on MediaFire and linked to it on an old blog on Jan 2, 2011. Luckily, there was [_one capture_ of the jar on MediaFire](https://web.archive.org/web/20240123154949/https://download1...) from oddly recently (Jan 23 2024). I downloaded and opened it on my 2023 MacBook Air, and it ran! Since it's Java, I'm guessing it runs on other computers, too :)
It was a delight to find it still working. Anyone else ever find an old program you thought you lost and get it running again?
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 :)
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!
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.
C++, C, even Fortran run just fine after decades.
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.
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.)
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.
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...
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.
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.
Consider donating: https://archive.org/donate
I recognize this is a very pessimistic take but ... for consideration
Fast forward to 2024, I still have the disks but no drive to read them. On the other hand, the notebooks where I wrote out some of the routines for the programs are still with me and I can read them. Says a lot about "digital archiving".
It doesn't, since you could easily buy a USB floppy disk reader
Also, I haven't done any specific climate control for the books or the disks. The notebooks are still readable and I can even tell the difference in the parts I wrote with a ball pen and a fountain pen. Many of the disks are damaged with fungal growth on the magnetic medium and I doubt I'd be able to read them even with a drive.
It's quite challenging to read off an old disk. Jason Scott (the famous digital archivist) had a nice talk on recovering the original source code for Jordan Mechner's Prince of Persia from ancient disks that mentions some of the challenges. https://www.youtube.com/watch?v=FnEWBtCnFs8
https://archive.apache.org/dist/ant/binaries/
Download the bin.zip distribution, unzip it, then run this comand:
java -cp "lib/*" org.apache.tools.ant.Main
Java is like Windows: it can run stuff written for it forever.
Fernflower works so well I don't always immediately notice I'm debugging decompiled code.
1 - JD-GUI - https://java-decompiler.github.io/
The code is a map editor for the Rockford ('Boulderdash') PC game. Unfortunately, the versions of Rockford in the wild, for download and online play, seem to be based on a later game engine and the map format has changed so the editor no longer works.
The code was designed to produce registered and un-registered versions, but I never released it into the wild.
If anyone has a copy of the original Rockford game version I'd love to know about it.
https://github.com/linker3000/Historic-code-PC-Pascal-and-AS...
https://web.archive.org/web/20010407081008/http://www.multim...
In fact I noticed 10 years after the publishing when I tried to run the applet that it didn't even run because the compiler of that time had generated invalid byte code (not caught by the JVM) or that the source code itself was invalid and that had not been caught by the compiler. "Compile Once, Run Everywhere", they said.
This should be able to run absolutely any Java in the browser.
Java backwards compatibility is real and it works absolutely fine unless you do bad things.
I won't doubt how java doing well, but other languages have it beat.
the reality is that is a strong ad against almost all modern frameworks, that may live for as little as a football season
Let’s be clear: I know that banks run on COBOL. Everyone knows that. Please don’t say it. I can name 5-10 other industries off the top of my head where this sort of longevity matters. But let’s not kid ourselves that the stuff we’re writing is even intended to last a long time.
Seriously though, this seems to be due to happenstance (well, commercial interest motivating great continuous engineering effort), rather than by design (forward-thinking) though; unlike, say, IBM's Technology Independent Machine Interface of AS/400.
You can still download a JVM for Java 21, but it's from weird third parties like Adoptium
Here are the JDK distributions supported by SDKMAN, a really good JVM-oriented package manager: https://sdkman.io/jdks
There's a couple of dozen vendors in there , including very weird ones like IBM, Microsoft, AWS, Azul, Eclipse, SAP, Redd Hat, and even... Oracle!
Likely 15k+ lines of code, not a single unit test; simpler times :)
https://www.macintoshrepository.org/11521-microbe-swarm
I suspect that it would run as is on a 68k Macintosh emulator.
[1] https://www.doomworld.com/idgames/levels/doom2/p-r/rurqta
I distributed it via public domain shareware listings - back then you had to send them off to a distributor and they would advertise their apps in the major computer magazines.
I used to get royalty cheques in the post! Which I think I spent on sweets.
Turns out most of the shareware from back then has been archived online so I was able to get it running again on an Amiga emulator and read all the immature embarrassing stuff that a 13 year old kid thinks belongs in a ReadMe… ;-)
And the Ruffle Flash Emulator still do not work with most interactive Flash Applications!
That is an achievement in compatibility.
It was 2 demos of my game engine project, one compiled in late 2001 and the other in 2002 based on the exe file timestamps. They used Win32 and OpenGL, and surprisingly work faster on my laptop with integrated graphics than on my beast desktop PC.
I mean, the original MF link literally still works (I intentionally break the link in case HN filters it)[1].
> Luckily, there was [archived] from oddly recently (Jan 23 2024)
You can see archiving reason on WB's index page [2].
In this case, it was archived due to "why: archiveteam, archiveteam_mediafire".
[1] http s:// www. mediafire .com/file/rwpl49xusm55s2a/WordFillVer2.jar
[2] https://web.archive.org/web/20240000000000*/https://download...
compiled Java class data, version 49.0 (Java 1.5)The calendar program uses document.write(), which is very embarrassing nowadays, but then again, that was what people did back in 2001.
Why is that lucky? The MediaFire link is still live anyway.
Actually I did some somewhat impressive graphical x86 assembly programs around 1994-95 which I would have really liked to see today, but I saw no value in those once I had done them. :/
That said, my first Java 1.02 programs from the 90's still compile and the old jars run surprisingly well too. Color me impressed!
The programs weren't fancy: one was for picking lotto numbers for my mam (the national lottery had recently launched in Ireland so it was a novelty.) Also I was 10.
Even before GitHub, probably. Dropbox was a big step forward, still.
Returns:
> Not Found
currently