211–220 of 279 posts
Earlier quoted context omitted.
Why do you say there are no reprocussions? It's a signicant issue in Congress, which writes all of the Department of Defense's checks, oversees them, investigates them, confirms their leaders, and makes laws controlling everything they do.
The DoD is Congress' baby. They will move heaven and earth to make sure the defense industry gets paid.
Worked with a guy ten years ago that would obsessively read these reports from the Pentagon. Here's a couple of his stories about the matter: https://www.reuters.com/investigates/pentagon/ and https://www.reuters.com/investigates/special-report/usa-mari... (very old and I apologize for my horrific javascript at the time.) It sounds like nothing has changed. Relevant to this crowd, maybe: "Most of the Cobol code the P…
Of course, devil's advocate would point out COBOL in 60s was written with a lot more focus on lasting in general. They didn't largely have the same general attitude of 'we iterate quickly with our script kiddies' as is prevalent today. Not that all software from then was wonderful. Or that COBOL magically guarantees great code. But, on the flip side, you can't say the code base isn't battle-hardened (to various liter…
I worked on enterprise cobol for nearly 20 years and can generally attest that cobol code from the 60s is absolutely nothing at all what you’re describing.
It’s brittle and constantly breaks, requiring 24/7 on call support for people to deal with issues so it doesn’t hold up the next days work.
It was not written with any semblance of engineering prowess. Most cobol written in the 60s was written by business managers, not programmers.
The reason it stays running isn’t because it’s battle hardened. It’s because nobody in their right mind would ever pay to untangle the unfettered mess.
Earlier quoted context omitted.
Outside of CA?
Even in Southern California, $250K is a very high salary for developers, at least in embedded systems, which is the space I’m familiar with.
Earlier quoted context omitted.
> Most explanations I've seen boil down to to "The US (or any other sovereign nation with control over their own currency) can print their way out of debt, it's literally impossible for the US to default." Its impossible for the US to be forced to default. Its quite possible for the US to make a political choice to default, and it has come very close to doing so.
Also, not only is it possible, but many countries have in fact chosen to default on debt denominated in their own currency, rather than subject their citizens to wild inflation and/or break norms around reserve bank independence. So, it could happen even if US is not forced to, I agree. For a starting point, see https://www.bankofcanada.ca/wp-content/uploads/2020/06/BoC-B...
Earlier quoted context omitted.
Start paying 250k a year for cobol developers and the problem fixes itself really fast. That or start migrating the system. Or more likely they keep using it until it completely breaks and then run to the government for a big handout to fix it. Easy to be irresponsible with other peoples money.
That could work if the existing code is actually up-to-date, correct, and if you have knowledgeable users of the systems backed by this code. The part about 'code corruption' makes me thing this is not the case. Worked at a big bank migrating some old code to new stack one time: - Original developers are gone. - Existing users don't understand the systems outside of their own narrow use-cases. - Code which was commit…
I remember the first time I saw this at a small company. The head programmer was the only one with the actual production source, despite a working source control system. He complained about how people didn't appreciate how hard it is to make builds work. I should have left when we lost three man months of code to losing email. I only left after screaming at the head programmer for refusing to stop making the repository unbuildable at all.
Earlier quoted context omitted.
Of course, devil's advocate would point out COBOL in 60s was written with a lot more focus on lasting in general. They didn't largely have the same general attitude of 'we iterate quickly with our script kiddies' as is prevalent today. Not that all software from then was wonderful. Or that COBOL magically guarantees great code. But, on the flip side, you can't say the code base isn't battle-hardened (to various liter…
COBOL in 60s was written with a lot more focus on lasting in general This is the same code that uses two-digit years and doesn't support lowercase letters?
Earlier quoted context omitted.
No, they couldn't. One person's savings is another person's debt. If everyone tries to save then no one can; this is the paradox of thrift.
https://en.m.wikipedia.org/wiki/Paradox_of_thrift#Criticisms Just because someone gives it a formal name doesn't mean it's true. >One person's savings is another person's debt. Only if you treat fiat currency (or bank deposits in general, the paradox you mention was formulated long before we got off the gold standard) as the only possible form of savings.
Earlier quoted context omitted.
"What, do you think we spent 10 grand on a fire extinguisher?"
Large fire extinguishers are high-pressure cylinders that require high-precision valves. There are fewer than 10 manufacturers in the world that can do it - half of them are in the US and the DoD will spend what it takes to keep it that way. You wouldn't want to end up like the EU and not have a single manufacturer that can do it, or (since Brexit) not have any that are legally allowed to import them. It's a good thi…