Progress and the death of cool code
-
About twenty-five years ago I wrote some code that did something similar. It was my import definition file for my script engine that define all the libraries and functions that were going to be imported along with their arguments and calling type. This was all loaded into shared memory once by the initialization process. This was for an automation system framework that was designed as a whole bunch of small, independent processes that were all implemented with the script engine. Everything was parsed and compiled to native machine code and it was lightning fast in both execution and load time. I was and still am pretty proud of that code. The last I heard there were over one thousand installed systems using the framework that are used to build all kinds of things. The thing is, it too is a bit rusty now. That was all done in the 32-bit world and one thing in particular was done a bit on the sloppy side. Enough so that if it is ever ported to the 64-bit world it is going to a HUGE amount of work. One amusing thing is we heard from a few customers who thought interpreted code would be too slow. It really wasn't but I figured out how to generate machine code on the fly so speed become a non-issue. Now, with 5GHz, multi-core processors being normal that script engine could be reverted to compilation for interpreted execution and still be more than fast enough. FWIW - the sloppy thing was handling time values which is REALLY important for those systems since a big part of their job is scheduling processing equipment. I should have used a specially defined type and the porting would be really easy. The way they were handled is going to be difficult to sort out but the clock is ticking on that. This is actually a potentially bigger issue than the year 2000 stuff was. That is because in 2037 the 32-bit time_t value is going to overflow so any systems that still use them are going to have interesting problems. I suspect that is a pretty large number of systems. Did you know the German railroad system still runs most of their trains with Windows 3.1? The US Navy still runs a large number of ships with Windows 98. There are tons of ancient, legacy systems in all kinds of places that need to be updated and if we don't get started soon big problems will arise. At the speed of government, thirteen years is really not that long.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
The New York subway system still runs on OS2. And Amtrak is probably still running on Visual Studio 6.0. The point being, it is really really hard to re-engineer an existing system. Sort of like re-building a skyscraper without tearing it down first. In other words, real code maintenance (aka, evolution) does not really exist yet. Monthly OS updates is not really a solution now is it.
-
Time marches in one direction. Code rusts. A long time ago I created a facility in which you could describe unmanaged standard C style API calls such that my code could create and implement an IDispatch interface around those functions, allowing them to be called from scripting languages like VBScript and JScript, as well as being callable from languages like VB (pre.NET) and VBA. It was pretty neat. Then .NET came, and now anyone can do it with
[DllImport]I actually felt a keen sense of loss with the advancement of .NET, because I spent a lot of effort making that work. I have mountains of code that's simply obsolete now. There are very few "classics" in software, and even fewer restorations of said classics. It really makes me wonder what *is* the actual shelf life of the things that I create, and how long will they survive once I'm on the wrong side of the dirt? Maybe I should have gone into metal fabrication.Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Just dump some of your dollars into sculpting. Maybe you can make a bronze (or something) casting where it is both code and sculpture. I don't suppose I care if my code lives on. It's cool to think about in some cases (and horrifying in others), but the stuff that really transcends time is probably all of the very hard to quantify or even see 'butterfly effect' type things. Like something you did in a codebase or something you posted nudging someone else to do different and on down the line.
-
Time marches in one direction. Code rusts. A long time ago I created a facility in which you could describe unmanaged standard C style API calls such that my code could create and implement an IDispatch interface around those functions, allowing them to be called from scripting languages like VBScript and JScript, as well as being callable from languages like VB (pre.NET) and VBA. It was pretty neat. Then .NET came, and now anyone can do it with
[DllImport]I actually felt a keen sense of loss with the advancement of .NET, because I spent a lot of effort making that work. I have mountains of code that's simply obsolete now. There are very few "classics" in software, and even fewer restorations of said classics. It really makes me wonder what *is* the actual shelf life of the things that I create, and how long will they survive once I'm on the wrong side of the dirt? Maybe I should have gone into metal fabrication.Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
I always tell people that programming is like building a house on sand on a hill, and someone added "when a rainstorm is coming" :)
-
The New York subway system still runs on OS2. And Amtrak is probably still running on Visual Studio 6.0. The point being, it is really really hard to re-engineer an existing system. Sort of like re-building a skyscraper without tearing it down first. In other words, real code maintenance (aka, evolution) does not really exist yet. Monthly OS updates is not really a solution now is it.
Yes, it is hard to re-engineer an existing system BUT it is not that hard to update a system to run on a current operating system and compiler because that usually does not require re-engineering. That is, as long as the OSs are of the same family. I know because that is something I have done many, many times. The most frequent problems I encountered were issues with interfaces. I learned to make interfaces as generic as possible and that considerably minimizes porting issues.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
-
Time marches in one direction. Code rusts. A long time ago I created a facility in which you could describe unmanaged standard C style API calls such that my code could create and implement an IDispatch interface around those functions, allowing them to be called from scripting languages like VBScript and JScript, as well as being callable from languages like VB (pre.NET) and VBA. It was pretty neat. Then .NET came, and now anyone can do it with
[DllImport]I actually felt a keen sense of loss with the advancement of .NET, because I spent a lot of effort making that work. I have mountains of code that's simply obsolete now. There are very few "classics" in software, and even fewer restorations of said classics. It really makes me wonder what *is* the actual shelf life of the things that I create, and how long will they survive once I'm on the wrong side of the dirt? Maybe I should have gone into metal fabrication.Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Part of the learning experience. I have learned many things loooking for the right thing while trying the wrong thing. Even my "great" software would have been better with the tools of today.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
Time marches in one direction. Code rusts. A long time ago I created a facility in which you could describe unmanaged standard C style API calls such that my code could create and implement an IDispatch interface around those functions, allowing them to be called from scripting languages like VBScript and JScript, as well as being callable from languages like VB (pre.NET) and VBA. It was pretty neat. Then .NET came, and now anyone can do it with
[DllImport]I actually felt a keen sense of loss with the advancement of .NET, because I spent a lot of effort making that work. I have mountains of code that's simply obsolete now. There are very few "classics" in software, and even fewer restorations of said classics. It really makes me wonder what *is* the actual shelf life of the things that I create, and how long will they survive once I'm on the wrong side of the dirt? Maybe I should have gone into metal fabrication.Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
The Model T can still be driven on today's roads (albeit not on the Motorway/Freeway/Autobahn). How much IBM 5040 software can run on modern hardware? And how much of it would you want to run, even if it were translated perfectly? Progress in computer technology within the last 50 years has been astounding. Based on clock speed alone, our processors are more than 5,000 times more powerful than they were in the '70s, and that's not taking into account the increased power provided by many instructions, multi-threading, etc. The Model T has a top speed of (shall we say) 50 kph. To match the increase in speed in computers, a modern car would have to do 250,000 kph*, IOW circle the Earth every 10 minutes! How many people, having access to a car like that, would take interest in a Model T? * Don't bother me with Physics; I know that is well over escape velocity. EDIT: replaced mph with kph. :-O
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
Time marches in one direction. Code rusts. A long time ago I created a facility in which you could describe unmanaged standard C style API calls such that my code could create and implement an IDispatch interface around those functions, allowing them to be called from scripting languages like VBScript and JScript, as well as being callable from languages like VB (pre.NET) and VBA. It was pretty neat. Then .NET came, and now anyone can do it with
[DllImport]I actually felt a keen sense of loss with the advancement of .NET, because I spent a lot of effort making that work. I have mountains of code that's simply obsolete now. There are very few "classics" in software, and even fewer restorations of said classics. It really makes me wonder what *is* the actual shelf life of the things that I create, and how long will they survive once I'm on the wrong side of the dirt? Maybe I should have gone into metal fabrication.Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
honey the codewitch wrote:
It really makes me wonder what *is* the actual shelf life of the things that I create, and how long will they survive once I'm on the wrong side of the dirt?
As I once told one of my coworkers (as well as an almost 80-years old carpenter neighbor of mine), coders aren't building cathedrals. Structures my old neighbor built when he was a young man are still standing today, and will probably continue to do so for a long time. I can't, and will never be able to, say the same about my work. If any of the software I've written over the course of my life outlives me, it means I'll be dead far sooner than I'd wish. Honestly I can't say I care too much if anything I wrote 10 years ago is no longer used today. A lot of it might be due to the fact that I might not even recognize it myself.
-
honey the codewitch wrote:
It really makes me wonder what *is* the actual shelf life of the things that I create, and how long will they survive once I'm on the wrong side of the dirt?
As I once told one of my coworkers (as well as an almost 80-years old carpenter neighbor of mine), coders aren't building cathedrals. Structures my old neighbor built when he was a young man are still standing today, and will probably continue to do so for a long time. I can't, and will never be able to, say the same about my work. If any of the software I've written over the course of my life outlives me, it means I'll be dead far sooner than I'd wish. Honestly I can't say I care too much if anything I wrote 10 years ago is no longer used today. A lot of it might be due to the fact that I might not even recognize it myself.
How Buddhist of you. I wish I didn't have a sense of attachment.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
How Buddhist of you. I wish I didn't have a sense of attachment.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Interesting perspective. I do take pride in some of my accomplishments (a well-written library, for example, that I'll keep re-using over and over again), but "attachment"? Nah, I'm not feelin' it. I can always re-implement something, which means I can't get too attached to the original. But, reading what you write about (with a lot of fascination from my part), it's clear we're not working at the same level. Not even close. And I do mean that in the best way possible. :rose: