Progress and the death of cool code
-
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
-
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:
Maybe I should have gone into metal fabrication.
Metal rusts. Mostly.
-
honey the codewitch wrote:
Maybe I should have gone into metal fabrication.
Metal rusts. Mostly.
Yeah, it does. And you might be surprised by the lengths people will go through to preserve or restore a nice example of say, a classic and/or custom car. I see no such effort in software, outside of the retrogamer nerds.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
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
What's the point? We are all going to be ruled by AI anyway :laugh:
Happiness will never come to those who fail to appreciate what they already have. -Anon And those who were seen dancing were thought to be insane by those who could not hear the music. -Frederick Nietzsche
-
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:
because I spent a lot of effort making that work.
You can still spend time if you want. Writing a hot pluggable in C# is fun.
honey the codewitch wrote:
and how long will they survive once I'm on the wrong side of the dirt?
Err...well that really doesn't matter does it?
-
honey the codewitch wrote:
because I spent a lot of effort making that work.
You can still spend time if you want. Writing a hot pluggable in C# is fun.
honey the codewitch wrote:
and how long will they survive once I'm on the wrong side of the dirt?
Err...well that really doesn't matter does it?
Maybe it shouldn't but it does to me sometimes. I don't have kids. Legacy is the only thing I'll leave behind.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
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
It may be obsolete now, but it sounds like it was cutting edge at the time. The Ford Model T was once leading edge!
The difficult we do right away... ...the impossible takes slightly longer.
-
It may be obsolete now, but it sounds like it was cutting edge at the time. The Ford Model T was once leading edge!
The difficult we do right away... ...the impossible takes slightly longer.
The primary difference between that code and a model T today is the model t is a desirable item.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
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
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?"
-
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?"
As far as time values I've learned to love the unix timestamp in 64-bits for cross platform transferability. If you need higher resolutions than seconds you can fractionalize that or add a trailer or whatever.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
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 wrote code over 40 years ago that I'm fairly sure is still running in telecom switches. It was a framework, so it might even still be used for a little development. And I know this to be the case for a framework I wrote over 25 years ago. If you're an AT&T mobile subscriber, that code runs whenever you call or text.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
Yeah, it does. And you might be surprised by the lengths people will go through to preserve or restore a nice example of say, a classic and/or custom car. I see no such effort in software, outside of the retrogamer nerds.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
The lack of source code is likely an obstacle here, as the alternative is emulation (WIN16 or whatever). It's interesting that the original ADVENT (PDP-10 FORTRAN) is still available, though I suspect it's been transliterated.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
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
That's the whole point... Being on the edge... Granted, what once was a complex beauty now can be done with a single line, but the beauty stays... And we are moving on...
"If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization." ― Gerald Weinberg
-
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 primary difference between that code and a model T today is the model t is a desirable item.
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.
-
I wrote code over 40 years ago that I'm fairly sure is still running in telecom switches. It was a framework, so it might even still be used for a little development. And I know this to be the case for a framework I wrote over 25 years ago. If you're an AT&T mobile subscriber, that code runs whenever you call or text.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.I am younger, so I can't speak about creations of mine older than 15-20 years. But I am pretty sure a couple of hundred-thousands (if not a couple of millions) have been using products done by machines I programmed in my industry automation days :)
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
Maybe it shouldn't but it does to me sometimes. I don't have kids. Legacy is the only thing I'll leave behind.
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.
I happened to see a real Model T at a car show a few years ago, and the owner told me that the engine makes 12 horsepower.
The difficult we do right away... ...the impossible takes slightly longer.
-
I happened to see a real Model T at a car show a few years ago, and the owner told me that the engine makes 12 horsepower.
The difficult we do right away... ...the impossible takes slightly longer.
They're actually a really affordable collector car because Ford sold so many of them. You can find them anywhere. Unfortunately it means they're not worth a whole lot even given their age.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I happened to see a real Model T at a car show a few years ago, and the owner told me that the engine makes 12 horsepower.
The difficult we do right away... ...the impossible takes slightly longer.
Richard Andrew x64 wrote:
the engine makes 12 horsepower.
I just googled the Model T speed record. It apparently was 42 mph (68 kph), so I was out by a bit. It doesn't change my basic argument, that the advances in computer technology are orders of magnitude greater than the advances in mechanics and similar technologies.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
