Live data from Hacker News

Elon Musk's DOGE team may need a crash course in COBOL

fastcompany.com

21–30 of 42 posts

Re: Elon Musk's DOGE team may need a crash course in COBOL

#21
post #17

Musk runs companies where software mistakes can kill people. I would give him the benefit of the doubt when it comes to software.

Musk runs a company that makes a product called "Full Self Driving" that cannot safely or legally be used for full self driving, and has therefore injured hundreds and killed north of 50 people. Under no circumstances should be be given the benefit of the doubt with anyone's safety, finances, or wellbeing.

This is a kind of weird rationalization where the conclusion leads the interpretation of the facts.

It’s hard to get away from the fact that space x and Tesla deal with critical systems. And by most accounts, they’ve pushed things forward

Re: Elon Musk's DOGE team may need a crash course in COBOL

#22

I tested it and it turns out LLMs can follow commands such as "Port the following Python code to COBOL", although it's certainly harder to validate the output is correct.

You don't understand. Your COBOL code may be 99.99999% right and still cause millions of dollars to vanish :poof: in a flash. If the DOGE team have this bright idea of getting an LLM to mess with the COBOL on mainframes there is going to be widespread chaos beyond human imagination.

Or, payments during an emergency. Say, avian flu.

Re: Elon Musk's DOGE team may need a crash course in COBOL

#24

I tested it and it turns out LLMs can follow commands such as "Port the following Python code to COBOL", although it's certainly harder to validate the output is correct.

You're porting in the WRONG direction. The existing COBOL code is undoubtedly using system utilities such as database management systems, etc. on the mainframe computers. And I doubt that you've written Python code that smoothly integrates into that system environment and just needs to be ported to COBOL. And I doubt that the mini-Musks can do so. (I'm not including the massive application-specific knowledge that you and they would or should need to grasp before attempting to insert code into the system.)

Re: Elon Musk's DOGE team may need a crash course in COBOL

#25

Earlier quoted context omitted.

> These government systems by necessity are not very complex, because the hardware at the time did not have capacity for anything too complex. This is possibly one of the most absurd takes I've read on HN in a while. I'm imagining someone trying to learn how a PC game programmed in Assembly works going 'how hard could it be, PCs in the 90s weren't that complex'

I'm always interested in hearing people out, but these legacy COBOL codebases are massive, complex behemoths. Certainly eyebrow-raising to hear someone say they are not complex.

Don't forget F77 codebases too.

Re: Elon Musk's DOGE team may need a crash course in COBOL

#26
post #12

Earlier quoted context omitted.

[flagged]

Didn't twitter already collapse now valued at single digit billions. The loss of traffic helped with the reduced headcount efforts. You don't need 80% of employees with 80% less dollars earned.

> In 2024, X (formerly Twitter) reported profits of $1.25 billion, which is about double its highest previous profit of $682 million in 2021.

People believing what they want to belive.

Not to mention that you talk about revenue and users, because it's hard to deny that technically Twitter is still working just fine, and now even has some new features, while in the past they were coasting tweaking their html for years.

On this very websites, all the "experts" in the industry were bidding how quickly Twitter will collapse after Musk fired all these "irreplaceable" people. Same ones that after 15 year still don't understand how Bitcoin works, or how it can have beneficial impact on the energy market.

Re: Elon Musk's DOGE team may need a crash course in COBOL

#27

Earlier quoted context omitted.

[flagged]

> These government systems by necessity are not very complex, because the hardware at the time did not have capacity for anything too complex. This is possibly one of the most absurd takes I've read on HN in a while. I'm imagining someone trying to learn how a PC game programmed in Assembly works going 'how hard could it be, PCs in the 90s weren't that complex'

As someone that actually wrote some assembly, including graphics in the 90s, I assure you that these games were waaaaay simpler than anything modern, also by necessity.

Re: Elon Musk's DOGE team may need a crash course in COBOL

#28

Earlier quoted context omitted.

> These government systems by necessity are not very complex, because the hardware at the time did not have capacity for anything too complex. This is possibly one of the most absurd takes I've read on HN in a while. I'm imagining someone trying to learn how a PC game programmed in Assembly works going 'how hard could it be, PCs in the 90s weren't that complex'

I'm always interested in hearing people out, but these legacy COBOL codebases are massive, complex behemoths. Certainly eyebrow-raising to hear someone say they are not complex.

"Massive", "behemoths". The same words you'll hear when you ask a man about their manhood, or their biggest catch. First hand source, so must be true.

I also trust government workers to give fair representation of their work. And what you SWE write on their resumes or what OKRs when filling time to justify paycheck. :D

They're a couple of database "tables" and formulas, what else they would supposed to be, think about it. They might be archaic, they might gnarly, limited etc. but they are no match for a modern next.js with react, in a docker container on a VM, running in a AWS datacenter, managed by Terraform, yadaydayda...

Re: Elon Musk's DOGE team may need a crash course in COBOL

#29

Earlier quoted context omitted.

[flagged]

>How many years do I need to wait for Twitter to collapse any moment now, because Musk fired all the "irreplaceable" people? To be fair, usage has likely dropped commensurate with staffing! >These government systems by necessity are not very complex I don't believe this is correct. CMS has a bunch of their source code on their website. The COBOL parts are quite expansive and there is probably a whole lot more out the…

> To be fair, usage has likely dropped commensurate with staffing!

The profit, which is what actually matters is up.

> I'm not sure a few 19 year olds are going to do better than this organization. It's hard work.

The problem was never technical. Ever tried to get stuff done in a bloated corporation full of incompetent people that just want to keep their jobs and don't want you to expose how relatively incompetent they are, especially the management? Things that a competent engineer in a startup could do in a day, are impossible to do. And in a government it's probably 1000-fold so.

Dumping some data from legacy system to a modern one is not a problem. The problem is firing people that can't deal with change. "You don't know what you're doing. Everything is sooo complex. You're going to break it. I've been doing it for 50 years, I know what's right."

Re: Elon Musk's DOGE team may need a crash course in COBOL

#30

Earlier quoted context omitted.

I'm always interested in hearing people out, but these legacy COBOL codebases are massive, complex behemoths. Certainly eyebrow-raising to hear someone say they are not complex.

"Massive", "behemoths". The same words you'll hear when you ask a man about their manhood, or their biggest catch. First hand source, so must be true. I also trust government workers to give fair representation of their work. And what you SWE write on their resumes or what OKRs when filling time to justify paycheck. :D They're a couple of database "tables" and formulas, what else they would supposed to be, think abou…

They're not complex in the Big O sense, they are complex systems in the sense that they have to incorporate and reconcile organizational knowledge from very different domains - e.g. Ron Jeffries' "Why Is Payroll Hard" http://wiki.c2.com/?WhyIsPayrollHard - while working in a predictable fashion with implicit requirements on availability and consistency, which the average web app stack more often than not leaves as "someone else's problem"
Post reply on HN