The cost of running government on COBOL (h/t Cowen) | Hacker News Reader

The cost of running government on COBOL (h/t Cowen)

papers.ssrn.com

18 pointschkaloon9 comments

Anecdotal data point: I worked, as a consultant, with a team of COBOL programmers that had been sent to some kind of "Java in 21 days" course. The system they were in the process of writing when I came on board used the "float" type to store money.

There was a point at which one of the programmers said he ignored the tests on amounts that were failing in reproducible ways because he thought they were wrong.

To this day I don't know the full cost of replacing all the uses of float with BigDecimal, but I'm glad one of my fellow consultants had a math and finance background and was able to sort it out.

Why did the COBOL folks use float and not know about the problems with IEEE-754 floating point?[1]

Because they had been using COBOL, which, because it was purpose-built for business and accounting has fixed-point arithmetic, handles money naturally.

1. https://0.30000000000000004.com/

Good grief... it's not like IEEE 754 is new by any stretch.

Yes but if you've spent your career working in a programming language that just does the Right Thing (per business/accounting rules), and you're thrown into a project with a language you don't know and need to do money math, it's not unreasonable to expect, until told otherwise, that 0.1 + 0.2 = 0.3.

The COBOL-turned-Java programmers I worked with may not have been the best (nor is Java all that), but the fact that COBOL does money the way we intuitively expect "out of the box" is why it remains in wide use. What other language has a built-in Money type that handles error accumulation and rounding the way accountants expect?

They should toss it to the Rust community, they'll happily rewrite it in Rust, might not even need to pay them as long as you allow them to always tell everyone they are Rewriting it in Rust.

As long as they will also take on the financial risk due to potential errors in their code.

Fails to assess the cost of COBOL vs alternatives. Junk research.

Looks like that's exactly what it does

"The delays caused a 4.4 percentage point relative decline in total card consumption in COBOL states relative to non-COBOL states."

Any idea what "card consumption" is? I don't think they mean punched cards.

I assume debit cards

Reply on news.ycombinator.com