Marianne Bellotti is an engineer who writes on mainframes, COBOL, TLA+, SRE and engineering teams.
HN links it in COBOL and mainframe threads, especially her hello world on z/OS and her piece on COBOL and floating point math.
This article expresses one piece of the problem that's increasingly suggesting to me that it's not hiring or job-hunting that's broken, but the model of employment itself.
(For yet another example of broken hiring, see this story, also presently on the HN front page: https://medium.com/@bellmar/sre-as-a-lifestyle-choice-de9f5a82d73d)
Skills assessment (and assertion) is difficult. Skills relevance is hard to assess. Incorportion and business as risk-externalising systems has worked rather too well (though the problem's hardly new), with much of employment risk being shifted from employers to employees, and from large employers to small ones (answering the anticipated small-business / startup response). The entities most able to manage risk are those most equipped to shift it elsewhere.
There's also the problems of offshoring, outsourcing, and shifting to the modern variants of endentured servitude, generally: employment-contingent temporary visa workers (H-1B in the US, similar equivalents elsewhere). And of gig, contingent, temporary, part-time, and other employment conditions, as well as of the tying of specific benefits (most especially healthcare) to employment status.
Don't even get me started on pensions/retirement, professional ethics, whistleblower protections, and labour organisation.
There was a link to another article [1] about how COBOL may be better suited to certain mathematical calculations. The article in question presented this iterative function:
x[0] = 4
x[1] = 4.25
x[i] = 108 - ((815 - 1500 / x[i-1] ) / x[i-2])
It blew up on iteration 14 using floating point, but COBOL could be programmed to go further (by using more decimal places past the decimal point).
[1] https://medium.com/@bellmar/is-cobol-holding-you-hostage-with-math-5498c0eb428b
Surprisingly there are reasons why running financial type systems in COBOL makes a lot of sense. Evidently COBOL really excels at foxed point decimal operations more so than other “modern” languages like Python and Java. Porting then off the mainframe isn’t a trivial exercise it seems.
https://medium.com/@bellmar/is-cobol-holding-you-hostage-with-math-5498c0eb428b
From what I've heard, redundancy and scalability in a single machine (like, you can hot-swap CPUs on a running machine and have lots of redundant RAM, etc.) and being able to run an OS with backwards compatibility all the way to the fscking 1960s or whatever.
That OS is… something: https://medium.com/@bellmar/hello-world-on-z-os-a0ef31c1e87f
A pretty good account of a "new to mainframes" person figuring out how to make their first Cobol program on z/OS: https://medium.com/@bellmar/hello-world-on-z-os-a0ef31c1e87f
From what I gather, it's an issue of floating point precision. See more here: https://medium.com/@bellmar/is-cobol-holding-you-hostage-with-math-5498c0eb428b.