I wish I could write all the business logic I write on an NES and never have to worry about requirements going bad. I guess the thing is, if you're writing anything on top of a network layer of any kind, eventually it's going to require patches unless you literally own all the wires and all the nodes in the network, like a secure power plant or some money clearing system in a bank that's been running the same COBOL since the 1960s. And since you're probably not writing code that directly interfaces with the network layer, you're going to be reliant on all the libraries that do, which in turn will be subject to change at the whims of breaking changes in language specs and stuff like that, which in turn are subject to security patches, etc.
In other words, if you need your software to live in the dirty world we live in, and not just in a pristine bubble, things are gonna rot.
Picking tools and libraries and languages that will rot less quickly however seems like a good idea. Which to me means not chaining myself to anything that hasn't been around for a decade at least.
I got royally screwed because 50-60% of my lifetime code output before 2018, and pretty much all the large libraries I had written, were in AS3. In a way, having so much code I would have maintained become forced abandonware was sort of liberating. But now, no more closed source and no more reliance on any libs I don't roll or branch and heavily modify myself.
Despite it being everyone's favorite shame language, COBOL's DATA DIVISION makes it uniquely well-suited for long-term stability. Common practice is to avoid binary fields. This means what you see in your program is what you see on the wire or in a file.
Building on bedrock is one extreme; the other is to become extremely fluid - build on quicksand but do it efficiently every time the quicksand shifts. AS3 may stop being useful, but if you can use some tool to recompile AS3 code to web JavaScript, you suffer no loss.
That's kind of my approach... KISS to the extreme. Something that's easy to replace tends to become surprisingly long lived and/or ported easily. I wrote a test launcher and client api for SCORM courseware in the early 00's. That code was later turned into a couple of LMS products, ported through a few different languages on the server and still effectively exists today. The DB schema and query code is almost exactly the same as baseline, except I didn't implement one feature that a decade in came across a course that used it and helped implement it.
Still friends with the company owner of that code. So I've had a bit more insight into follow-up on code over 2 decades old that isn't so typical for anything else I've done.
Another example is people from EU making fun of US buildings.
Lasting centuries may or may not be preferable.
There are places where you want to cheaply rebuild from scratch. Your castle after tornado and flooding will be irreparably bad. Most castles suck badly by not taking advantage of new materials and I myself would not like to live in 100 yo building.
Same for software, there are pieces that should be build to last but there are applications that should be replaceable in short time.
As much as I am not fan of vibe coding I don’t believe all software should be built for decades to last.
HaXe is great fun as a language, and I would definitely consider it now if I were writing a new game from scratch. But I never found anything to be a straightforward port from as3. There was too much unsupported particularly in networking. Too much of what I wrote relied on Adobe's NetConnection and socket implementations, plus other .fl packages that never made it over. Not looking at it right now, but that was pretty much the wall I hit at the time around 2019... there was no build target that wouldn't require rewriting the whole way a multiplayer game platform handled networking to get around the sandbox limitations that you could work inside of in AIR or Flash.
Maybe I was just kinda dejected and could have solved it, but instead I moved over to TS and PixiJS, ported some necessary logic and started my whole stack over.
Thanks, I appreciate the answer. Did you consider releasing your AS3 code under a Free Software license? Some people could find it worth to port it to Haxe.
>And since you're probably not writing code that directly interfaces with the network layer, you're going to be reliant on all the libraries that do
That said, why the network layer doesn't run as a socks or http proxy or something? That would greatly simplify network logic. All network libraries provide old interfaces like streams and requests.
In other words, if you need your software to live in the dirty world we live in, and not just in a pristine bubble, things are gonna rot.
Picking tools and libraries and languages that will rot less quickly however seems like a good idea. Which to me means not chaining myself to anything that hasn't been around for a decade at least.
I got royally screwed because 50-60% of my lifetime code output before 2018, and pretty much all the large libraries I had written, were in AS3. In a way, having so much code I would have maintained become forced abandonware was sort of liberating. But now, no more closed source and no more reliance on any libs I don't roll or branch and heavily modify myself.