CanadaPlus

First off, thanks for the help!

Really responsible devs write the unit tests first, because you should know what you’re going to put in and what you’ll get out before you start writing anything.

I've obviously heard the general concept, but this is actually pretty helpful, now that I'm thinking about it a bit more.

I've written pretty mathy stuff for the most part, and a function might return an appropriately sized vector containing what looks like the right numbers to the naked eye, but which is actually wrong in some high-dimensional way. Since I haven't even thought of whatever way it's gone wrong, I can't very well test for it. I suppose what I could do is come up with a few properties the correct result should have, unrelated to the actual use of it, and then test them and hope one fails. It might take a lot of extra time, but maybe it's worth it.

How do you deal with side effects, if what you're doing involves them?

Interesting. I wonder why they didn't just move it to somewhere with less radiation? And clearly, they have another more trustworthy machine doing the checking somehow. A self-correcting OS would have to parity check it's parity checks somehow, which I'm sure is possible, but would be kind of novel.

In a really ugly environment, you might have to abandon semiconductors entirely, and go back to vacuum as the magical medium, since it's radiation proof (false vacuum apocalypse aside). You could make a nuvistor integrated "chip" which could do the same stuff; the biggest challenge would be maintaining enough emissions from the tiny and quickly-cooling cathodes.

That's what I would have thought. What exactly is a typical alternative approach, commercially? Open source projects might maintain a wiki or traditional website, and documentation files within the source itself.

Also in professional env if a company cares about it’s trade secrets it will not rely on 3rd party solutions for all of it’s communications.

This one is big, and shouldn't just be professional environments. People rely on open spy devices in both environments because they're dumb.

Element would be a great alternative. Signal would also be decent.

So how do you write a good test? It's like you have to account for unknown unknowns, and I don't really have a good theory for doing that.

Right now, I usually end up writing tests after the code is broken, and most of them pass because they make the same mistakes as my original code.

I wonder if there's an available OS that parity checks every operation, analogous to what's planned for Quantum computers.

Mmm, race conditions, just like mama used to make.

From the perspective of the people who make the crap, corporations are the users.

He got a hand-me-down iPhone because he's poor, and has decided it's better than no phone, but is sad it's still a walled garden despite other people being rescued.

Is there a joke I'm missing?

New Guam, maybe.

Yeah, maybe somebody can translate for you. I considered using something else, but it was already long and I didn't feel like writing out multiple loops.

No worries. It's neat how much such a comparatively simple concept can do, with enough data to work from. Circa-2010 I thought it would never work, lol.

The thing people always overlook is that these legacy systems are only still running because they're super important. Nobody's hiring a junior COBOL dev to maintain NORAD, and hopefully nobody's contemplating putting ChatGPT in charge either.

The move if you want this kind of job is to learn a language that's not quite a dinosaur yet, and have 20 years experience in 20 years. Perl or PHP maybe.