nit sure how else it'd work?
Well, I mean, you could just not be shit and lazy and do backwards compatibility.
> When was the last time you actually compiled 20 year old .net code?
One of the things I learned from my first boss is that if you move job every 5 or 6 years you never have to do this for any language. So far he's been right.
So all your arguments about the longevity of .net code are academic. It's easy to avoid responsibility for your earlier work if you make yourself hard to reach. I guess that's an approach that could work for some people :P
Seems unfair given your earlier point about VB6, no?
My earlier point was that sticking with VB6 wasn't really a reasonable path, it was a path that would lead to increasing resistance and hostility and incompatibility from MS, culminating in last year when they finally cut you off and your code stops running (something I didn't know about, thanks for the ammo!). And all this for no reason at all other than to sell the replacement MS product.
Ironically, now that they have dropped the VB runtime the best upgrade path for that guy who stuck his head in the sand and kept using VB6 is to switch to Linux and wine, where it still works just fine and will continue to work for the forseeable future.
So, no, I wouldn't say unfair, I'd say factual.
In fairness, they only dropped backward compatibility for the run time last year,
Yeah, but that was not done for any technical reason. If MS loves open source so much these days, why didn't they open source the VB runtime and let the community maintain it? Did they forget that they love open source on that day? But hey! look! They open sourced their calculator! And Windows 1.0! Wow! Aren't they kind and caring and giving and not at all just releasing useless crap as open source in an attempt to manipulate their public image?
so he wasn't completely wrong. They even offered VB.NET as a migration path for VB devs to ease the pain...
As of last year he is now fucked unless he refuses to upgrade to a modern MS OS, making him vulnerable to all kinds of nastiness. Or he could switch to Linux and wine.
VB.Net was not "a migration path", it was an opportunity to rewrite all your code in an incompatible language inseparably tied to a godawful platform with unknowable future support run by an organisation which had just dropped your tech stack leaving you with no migration path.
not a lot more they could do really.
Well, I mean, they could have just not been shit and lazy and done backwards compatibility. Or they could have offered an actual migration tool. Think "File -> Import VB6 project". But no, that would have cost them a little bit to develop. Instead, let's make it an externality and force every VB6 dev in the world to "just" rewrite all their stuff.
So I'm guessing you're not a vim or emacs user then?
No, not so much....
30 year old code mate. I run it every single day. There's a bunch of it in the FOSS world, where we're not on a forced obsolescence treadmill so that MS's stock price can stay steady, and where things tend to stay compatible with themselves so you're not forced to rewrite your stuff all the time.
An interesting side effect of running this 30 year old code is that because it's 30 years old it's diamond solid - more solid than rock solid. When software reaches this kind of maturity you get to the point where it might even be possible that it has zero bugs in it. I know right, what a thought.
that 17 year old code.... is it multi-threaded to leverage multiple CPU cores?
Does it make effective use of the GPU for math intensive stuff?
Doesn't need to. It's just some business logic. But there's no reason why it couldn't if it needed to. Instead, we didn't spend any money buying a GPU.
How does it feel about 64 bit OSes?
You mean like the one it's running on? It doesn't seem to mind. The OS upgrade from 32 to 64 bit was really not even a thing, went really smoothly, no downtime.
Have any libraries you used been patched?
Every single library it uses (and the whole OS) are automatically updated weekly without anybody even bothering to look at the logs. This has caused 0 problems in the time it's been running. Unless you count the couple of times that there were internet problems and it had to try again the next day or whatever, or the time I logged in and manually upgraded stuff when heartbleed happened
I presume the client hasn't been able to move datastore to something more free?
One of the beauties of using free software is that the concept of moving to "something more free" doesn't really apply. It's already free. There are several implications that go with this. One is that the vendors don't make it hard to move to something else. I know right. This means the client can do what they want with it without artificial encumbrances imposed by the bottom line of some company that doesn't care about them at all. If they wanted to switch to a different database engine, for example, that wouldn't be a huge issue. We've switched fileservers and upgraded storage capacity a bunch of times. Fun fact: the first fileserver we used way back in the olden days was a windows server box. As someone stuck on the MS stack, this is a phenomenon you might not be aware of. We call it "interoperability" :P
they're all problems I've solved before.
Damn, I'm sorry. I hope that doesn't happen to me - I'm only at 3 decades and I'm still finding things. Maybe you should think about game dev? I hear you can do that on .net.
Louts 3rd Law of Coding: Write it in COBOL and it'll live forever. Cobol McCleod of the Clan McCleod, as they said in Highlander.
.NET is built to last
...exactly as long as the overlords decree it will last, and they haven't announced that they're dropping it yet, and they only drop tech stacks causing hundreds of millions of hours of unnecessary work for millions of devs the world over every decade or so, so let's just assume it's staying around forever!
(I will grant you that open sourcing it does alleviate some of this, but they haven't open sourced the whole thing, so that's not really an argument)
you just *might* have to prod it a little every 5 or 10 years
...assuming it doesn't get deprecated tomorrow, something that the company in charge has only done a couple of times before...
20 years is way beyond the lifespan of modern hardware so unless you build it cloud native, you're going to have to do maintained somewhere down the line.
yes, but that maintenance doesn't tend to be imposed on me by the political whims of some third party who explicitly doesn't care about my use case. Rather, it tends to be for technical reasons. Which means that a) it's more reasonable and b) less frequent.
You won't believe this, but the place you bank with does what my bank does - they buy failed technology museums so they can asset strip the mainframes for parts. I shit you not. They always look for firesales when old companies fail too - Woolworths and others had a few that went for a good price because all the banks were interested and bidding against each other.
Oh I totally do believe it. That's awesome and hilarious. And I want the job of mainframe wrangler, that sounds fun. I heard a story that one of them banks wrote an emulator for the mainframes rather than trying to reimplement the system running on them.
This has been a fun chat. Thanks. :)