The first major piece of code that I ever wrote was a publishing workflow management system for a major newspaper. It routed page images to presses and generated pdfs of each page in each edition of the newspaper and made pdfs of each day's newspaper editions and published them to a static website where they were archived.
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
In Norwegian we have the (made up, but widespread) word 'Permasorisk' (a mangling of permanent and provisorisk) to describe a solution which is by no means meant to be permanent, but solves the original problem well enough that there no longer is a need for the permanent solution...
It was never a temporary 'fix'. The product eventually spun off into a new company and was recently acquired by a PE firm.
But yeah, creating software - or any kind of process actually - results in maintenance. If something is used a lot -> too many people depend on it. If the number of consumers/users isn't documented -> you don't know if you can turn it off, but for this problem you can inspect a year's worth of log files :)
I had a job once trying to help the government un-fuck a janky codebase that they were in the process of paying billions of dollars for. I remember opening a file that had some issues (IIRC it could only be compiled with a specific discontinued compiler) and seeing a comment that the file was created on my literal birthday. Was quite the surprise.
Great story ! I'm proudly responsible for a small perl script that pre-processes SWIFT messages before sending them in a back-office banking Java app. It's barely 10 yo but I'm not a dev, and I suspect it will probably run forever.
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.
For Perl4? Not that likely, IIRC CPAN was started in '95, after Perl 5 came out which introduced most of the packaging semantics. I think Perl 4 basically had an "include" equivalent.
Don't remember anyone doing OO back then with it, either. Would be interested to know how that worked...
It's in moments like this that I miss the hacker news magazine[0], because I had relatively high certainty that when stories like this popped up, the poster in question would get interviewed and their story would appear in the next edition.
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 :)...
> asked me a few questions about what OO Perl is because he wanted to make a few changes
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.
i never wrote perl in any serious fashion, but i've always tried to use as much information in the source so i can figure out how i did it. I enjoy reading the submissions to code golf challenges, though. A few of the more esoteric language users have let slip they write a compiler to go from readable code to the target unreadable code.
Whenever i see terse C or load bearing perl it does look like line noise.
> The whole thing was written in perl 4 style OO Perl
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.
I architected/managed/maintained a perl web application starting in 2001 for a dot com. I still work with it today and the application/company recently sold to a new company for $24M USD.
> It is used by hundreds of people daily, who by all reports absolutely hate it.
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!
The wayback machine is pure nostalgia. Every time I go there I’m truly amazed at what it’s like to have a society wide memory that automatically captures these different moments of our lives.
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.
Reminds me of some reddit post with a link to some page with some local history, but all of the image links were broken. Within a few minutes I posted the link to Wayback and they were delighted because they happened to be archived there.
Internet archive started making their own crawls in late 1996. I believe the oldest captures in the wayback machine are from data donated by alexa starting from January 1996 [1]
One of the first programs I ever wrote - a program to find valid English crossword fills given a grid pattern with optional partial completions.
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?
EDIT: As a couple observant folks pointed out, the original MediaFire link actually still works, so WB machine saved the day by making it possible to find the link, but the jar was also still hosted on the today-internet :)
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!
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.
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.
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.
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).
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.
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.)
> 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.
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.
> 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.
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.
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 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.
I normally echo this sentiment, and I can easily imagine an outcome through which the money could pay for lawyers, but in the ongoing discussion about their court case <https://news.ycombinator.com/item?id=40201053> there was a comment that predicts any money they get is just going to end up in the pockets of Hachette when they eventually lose :-(
I recognize this is a very pessimistic take but ... for consideration
My earliest "large" program which I can remember was a drawing program I wrote in GW BASIC. You could draw figures, change brushes, I think it had a crude filling function and a few other things. In my innocence, I backed it up onto 5.25" floppy disks, labelled them neatly and put them in a box. This was in the late 1980s.
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".
FYI if you want to get things off a 5.25 floppy, you can get a Greaseweazle for $25 and use it with any 5.25 drive. https://decromancer.ca/greaseweazle/
Are you me ? I wrote an exact program like this in GW Basic back in the day. I remember adding the ability to draw coloured lines but I had no way to verify since my computer monitor was one of those with green coloured pixels. Finally got to see everything in full colour at my school lab and was so thrilled. Those were the days ...
I haven't looked recently but I did search a while ago for a 5.25" USB floppy drive but never found any. Several 3.5" though.
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
One of my first jobs was writing a Perl script in 1996 that did an incredibly mundane set of checks on some routers in a datacenter (using this really cool new technology "BGP") and offered essentially a public REST API (though we didn't call it that back then) you could periodically poll to see their status. Every so often I check to see if it's still there, and it always has been. I really hope it makes it to 30 years.
If you are so inclined, a decompiler might be able to "recreate" a big part of the source code. IntelliJ IDEA's one (Fernflower) works well, its fork Vineflower seems like an interesting option too. Both are released under Apache 2.
Fernflower works so well I don't always immediately notice I'm debugging decompiled code.
Nice, didn't know about fernflower, thanks for the recommendation! I use JavaDecompile (JD-GUI)¹ too much and is already in my workflow, but from insights like this i see some nicer/better tools.
One of my first pieces of code from my first job in 1997 still exists and runs according to a long suffering colleague that still works at the same place. That also means the code has gone from SCCS -> CVS -> Clearcase -> Perforce -> SVN -> Git. That's enterprise development for you.
Mine was from 1984, I recovered basic program from a Commodore 64 disk using a USB to 1541 controller. A character sheet creator for a "homicidal maniacs" role playing game my school friends and I created :-).
I found some old Turbo Pascal code I wrote in the late 1980s - early 1990s and managed to compile and run it under a DOS emulator a few years back.
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.
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.
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.
With Java 11 they hid a lot of internal functions that people had used in their code, so breaking things. But that was never really part of the public API, so strictly not a breaking change.
I remember moving to Java8 changed the iteration order of hashmaps etc, which also broke some stuff for us. But again, that was mostly our fault for relying on unspecified behavior.
With Java 11 they only hid it, you just need to pass some parameters to get it working.
When it truly broke, I believe, was only on Java 21, which finally removed some clutches people had been using to work around the new limitations.
True, I think since Java 17 they have been removing really obsolete stuff.. I think that's when they removed CORBA from the JDK as well (though you can still get it as a library I believe). Same with Nashorn (the JS runtime).
That much it was all about JSP/XML and stuff; J2EE too. JDO came soon after too. The applets did exist and (javax.)swing was a thing - but it was far from the focus... and of course Java was still considered slow.
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.
Except they're not in widespread usage, so aren't relevant.
No grads are going "gee, do I go with a .NET shop, a JVM shop, or a BEAM shop?"
And as for Common Lisp, which implementation? They can't even be compatible amongst themselves, so I'm dubious that SBCL CL from 13 years ago would just work.
> And as for Common Lisp, which implementation? They can't even be compatible
> amongst themselves, so I'm dubious that SBCL CL from 13 years ago would just
> work.
> Except they're not in widespread usage, so aren't relevant.
I don't know any java programmers either. Apparently people use java, I just dont know any that do it willingly. I'm sure they -must- use it, but erlang/fortran/etc as mythical to you as java is to me.
> No grads are going "gee, do I go with a .NET shop, a JVM shop, or a BEAM shop?"
Fresh grads don't know better, they take whatever pays. Businesses choose the cheapest (not the best) option and grads don't have the experience to choose better. Grads choices are not a measure of quality or desirability.
> And as for Common Lisp, which implementation? They can't even be compatible
> amongst themselves, so I'm dubious that SBCL CL from 13 years ago would just
> work.
My SBCL from 2010ish works, I've patched it up and improved it over time, but I haven't tried to run the original, it probably does. Its been through svn to git so I've lost the history, all of this is as anecdotal as anything else. Previous lisp code that I wrote was trivial and ran out of the box on SBCL, however the code is very self contained and not 'networked' or 'modern'.
My erlang code however has been running in a cluster since the early 2000's, it has also been through several releases for additional features, however I no longer have access to that code so I can't validate what has been done to it for the last decade.
I like your arguments, I just dont think we're coming from the same historical viewpoint.
The Lindy effect assumes you have no other information about the thing you're estimating. Obviously if I know the thing is on its deathbed, I can't invoke the Lindy effect. Similarly, a hundred-year-old language one person uses any more isn't likely to last another hundred years.
Given the relative sizes, I wouldn't bet on Common Lisp outlasting Java just because it's older.
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.
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 out LONG before then. The business went bust and the only surviving copy is on some developer’s personal computer. Darlene from accounting left and her replacement likes to do things differently, so all this custom stuff was replaced with something off-the-shelf. Your $40B unicorn dating network very unceremoniously fell from the charts after Gen Z decided to throw their phones away and connect in person like we used to. After all that, you’re left there holding a perfectly functional(?) solution to a problem nobody is asking to be solved anymore.
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.
>> 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.
Longevity is very important in enterprise apps. Companies are full of small services / utilities which were developed many years ago, work for the most part just fine and need to be touched only rarely to fix a bug which just started manifesting, add a small feature or enable some integration.
>>“This code should last 20 years” should, for most people, be fairly low on the list of desires for a technology stack.
>> But let’s not kid ourselves that the stuff we’re writing is even intended to last a long time.
Well, it depends. If you write custom software for enterprises, they very much see it as a long term investment. Software grows with the company and is embedded in it. Nobody wants to pay for complete rewrites every five years..
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.
bit late on "by design" party - java 'binary' (not source, which is easier) compatibility is an exceptionally important feature. E.g. changing method signature like void x(int val) to void x(long val) does break the binary compatibility and it means the original method has to be preserved, potentially as something like void x(int val){x((long) val);} - which just calls the new method by casting val. It some cases the original method might be marked as deprecated.
On the Java Mailing Lists, the creators/stewards of Java are constantly fighting back so many feature requests BECAUSE those features would threaten backwards compatibility. And that mailing list has been going on for a long time now. You can see feature requests (and their subsequent rejections) going as far back as the late 90's lol
Remember, Java came from Sun. Backward compatibility was an absolute requirement at Sun for nearly everything. Compatibility is hard-baked-in to the culture.
Oracle plays more loose, but a lot of the people are still around.
Adoptium is a JVM from the Eclipse Foundation. They're hardly weird, even if the branding is. It's basically "people into JVMs not controlled or licenced by Oracle that work good".
I never realized it was from Eclipse! They've cleaned up the webpage where it's a bit more clear now. I always figured it was a weird consultancy or something like Gluon - where there was a paid product when you dig a little
Thanks for clearing it up. Hope they rebrand and drop the Adoptium name eventually
It used to be called AdoptOpenJDK, and was a project that essentially just provided prebuilt binaries of OpenJDK.
But post several Oracle changes that I admittedly have not kept up with, they have grown in scope and also been forced to remove OpenJDK from their name. They went with Adoptium, to keep the Adopt part that got them famous.
My first piece of code (substantive) was an ecommerce platform (frontend and backend). Complete overkill, and the startup was dead a year later, but the project itself was fun.
Likely 15k+ lines of code, not a single unit test; simpler times :)
Lisps that support macros are pretty much infinitely backwards compatible. Even across dialects. I wrote a set of macros to be able to program in a subset of Scheme and Hylang, and run that code on either :)
One guy form the PDP-10 'tribe' wrote a Maclisp interpreter in Common Lisp with relative ease. 90% of the code would still run as is, and maybe under Elisp too...
The oldest thing I've written that I can still find on the Internet — the original disks are long gone — is a microbe simulator I wrote about 35 years ago. Apparently, at least two people archived a copy:
I have Objective-C software for iOS that was built for iOS 3 that still runs on the latest version of iOS and people still pay for it. Strange how language stability is an achievable goal.
Damn, that makes me want to see if I can dig up the asm code I wrote for the TI-83 and run in on an emulator on modern hardware. Really happy for you that you were able to find that jar!
I also found mine! The first program I wrote (aged 13) was in 1991 - it was “RADBench” a program for the Commodore Amiga that created a slimmed-down workbench that lived on a RAD disk (like RAM but survived a soft reboot). Meant you could use your computer without having to reinsert the disk containing the main OS binaries whenever you wanted to do anything.
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… ;-)
My first "major" program was a ASCII art based Super Mario Bros clone in Turbo Pascal from 2005. I don't have it anymore, but since Turbo Pascal hasn't changed and text terminals haven't changed, I'm pretty sure it still works.
This is cool. I went there to check if I can find some of mine and found the page that links to some of my public downloads, unfortunately, none of the Zip files were archived.
And the Ruffle Flash Emulator still do not work with most interactive Flash Applications!
You might try building Ruffle from source. I’ve found that online versions don’t work for the games I want, due to using an outdated version of Ruffle.
My son found some of my old java code from 20 years ago and managed to get a couple of the programs to run, with some very minor modifications. The java applets not so much, because no browser has had support for applets for a decade or so.
I'll have to check it out, we spent a few minutes looking and it seemed like they don't ship it anymore, but I guess you can still get Java 8 from Oracle and it should include it.
I've recently dug up some of my first "larger" scale projects that I implemented in the early 2000's, including compiled executables, which managed to run unmodified on modern Windows.
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've found some of my old .jar's (some small games) written on Windows in the 2000's. They still run on Linux 20 years later. That's why I like the JRE.
I recently realized how much data the wayback machine is archiving when I found my old webpage with dozens of videos and photos of my puppies being born and they all worked.
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.
They started with Java 1.0 and 1.1 - then to "Java 2" at version 1.2, so you have Java 2 version 1.2 ... they then stuck with that through the version after 1.4 - but rather than 1.5, that was special as it was Java 2 version 5.0 ... thereafter they're just numbered with the plain number.
Oh, that's the JRE software version - that's completely different from the language version.
For the JRE, I want to say that they stuck with the 1.version.minor numbering (although the last version with a minor other zero was I think the Very Popular And Probably Still In Prod 1.4.2), with updates suffixed with "u" + number through the Java 8 series, but then with 9 they switched to version.minor.update instead.
It's completely incomprehensible; not even Oracle can keep it straight.
Plain old JavaScript (without frameworks) holds up rather well. My simplified blackjack game from 1998 (modified in 2003) and a calendar program from 2001 (probably written before then) still work in a modern browser.
The calendar program uses document.write(), which is very embarrassing nowadays, but then again, that was what people did back in 2001.
I wrote a similar program once. To get it to be efficient I had to use a bunch of heuristics including scrabble scoring words, so it would prefer words with low scrabble scores which were more likely to fit in with other words.
So I’ve turned into an old man screaming at the sky. 2011 is not that long ago! Lot’s of production code from that time can be still considered fairly ”fresh”.
Wow, I did some work in summer 1996 in java, web applets! Would be awesome to find that again, but I think the chances are less than slim for that happening.
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. :/
It was quite different before the internet. I'm still holding out hope of finding some of my old BASIC programs from the 80s on a 5¼-inch floppy disk in my parents' basement. But they are probably gone.
I found some of my first BASIC programs recently, written in 89/90 on an amstrad464. They're on cassette tape. I have a tape deck with line out, but I don't even know how to start trying to get data off an "audio" cassette tape these days?
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.
Eh, not really. Even before source control was widely used by non-professionals, there was still the habit of copying all your stuff over whenever you upgraded to a newer hard disk. I've got random stuff sitting on my hard drive that probably dates to my first PC in around 1996.
I wish I had the Logo and BASIC programs I wrote for the c64 in the early 80s. I still have the disks, so there's vague hope. Even more, I'd love the animations and images I made on the Amiga later in the decade, but that's more unlikely.
It can still be downloaded via the file on the repo, just not using that direct link in the description. I'm not sure how the maintainer came to determine that is the link, since I'm almost certain that never would have been the way.
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.