waltman

Exploiting your opponent's weaknesses seems like a perfectly cromulent strategy to me, whether your opponent is made of meat or silicon. Go humans!

Sure. My point was just that it's more difficult than it seems. Also this would mean that lines like

add x to y giving z

become something like

cobol_add_giving(&a, &b, &c);

which is a lot less readable.

It’s certainly possible; after all, the GnuCOBOL compiler is written in C. A large part of every COBOL program tends to be simple move and arithmetic statements that seem like they should be easy to port. The difficulty comes with the data declarations. COBOL’s pic statements don’t just define length and whether or not they’re numeric. They also come with complex behaviors that are enforced at run time. For example, anything that’s a pic 9 is stored as a sequence of 0-padded text digits, but you can also do arithmetic on them. They work like a car odometer in that if you add 1 to a variable that’s all 9’s, the result is all 0’s. They also allow you to do arithmetic on currency amounts (like I do in the article) exactly, without having to worry about IEEE floating point round off errors. That’s another reason the banking industry likes COBOL.

It's also solved by modern editors that do syntax highlighting. Both emacs and vim flagged that period as an error when I was working on the example in the article. But sadly the editor I was using at the time did not.

When I wrote the article I didn't have access to code I worked on 2 decades ago, and if I did I couldn't have used it in the article anyway. This was indented to illustrate the problem with problem with column 73, not to handle all possible cases.

Having said that, situations like would come up sometimes. You really did have to decide ahead of time how big field could be. You could leave extra filler bytes in your tables (literally named "filler") but it was still a big hassle to deal with.

I'm the author of the article, and I linked to the source of those numbers. The numbers seem reasonable to me too for the same reasons dcminter gave. One other reason is COBOL is a language that lends itself to copying and pasting old code instead of writing subroutines, so that leads to a lot of lines of code.

I'm the author of the article, and to be honest the only reason I did it this way was to make sure the period ended up in column 73. I've presented this in talks about half a dozen times now, and you're the first person ever to notice that. Congrats!

My experience with COBOL was on Stratus computers running the VOS operating system. This was a better environment than mainframes, but I'm still ambivalent about the language.

It's certainly true that there's a lot of boilerplate verbosity involved in reading files in COBOL. But once you've done that, parsing out the fields will likely be much simpler than in most modern languages. Records like this are still produced at government agencies such as the US Census Bureau. I've often wondered if it might be simpler to do the parsing in COBOL and then pipe it to another language to do the rest of the processing.

COBOL structures are better for fixed-length strings than C structs are because C really prefers strings do be null terminated. In C you've got to specify the length of each string, whereas in COBOL the compiler takes care of that for you.

That 72-character limit came about because the most popular IBM punch card reader at the time COBOL was being written could only read 72 of the 80 characters on a card. Once you know that anything after column 72 will be ignored, you can repurpose those columns for other things. At my shop we used them to denote revision numbers. And once practices like that get set, you're pretty much stuck with the older formatting rules.