Originally published at: https://boingboing.net/2020/11/18/why-cobol-will-never-die.html
Originally published at: https://boingboing.net/2020/11/18/why-cobol-will-never-die.html
I’ve met several COBOL programmers over the years. In my case, every single one was a cool retired elderly woman who just mentioned their skill in passing. They’re grandmas with secret identities, living their lives until a call comes in and they spring into action.
Their numbers are dwindling, of course, and I don’t think there are any training programmes to replace them.* After decades in tech, I know that the final transition to new code bases necessitated by that is going to be a rough and kludgy one.
[* ETA: maybe in the military?]
My dad was a COBOL purist from when he started using it (he started in computers with the USAF in the 50s) until his death in 1992. This headline would have made him happy.
It’s not just the technical challenges. Knowing COBOL is just half the issue. The COBOL generation also knows the business requirements and procedures at an intimate level. They know the constraints that the organisation has. They know why that odd test is there, and what can go wrong if you don’t do that test. Hell, in some cases they probably created many of the business procedures, as they may not have existed before automation.
The clue is very much in the name - COmmon Business Oriented Language. When they wrote these systems they weren’t just writing software, they were automating entire ways of doing business. If their code seems clunky and inelegant to modern eyes, then that’s because the business process is clunky and inelegant - as so many often are, for good reasons.
A lot of teaching modern software development seems to focus on abstraction. On trying to get to a codebase of platonic ideals that’s somehow “pure”, untainted by the humdrum realities and awkwardness of life.
It’s a curious and subtle difference. COBOL developers were just trying to automate with computers, modern developers are trying to do things with philosophically optimised tools.
I suspect that when many of the COBOL replacement codebases go live, it’s going to be one helluva shitshow…
Very true. I don’t know COBOL, but this has been part of my own professional value proposition since I started consulting. Back when I started decades ago, my clients were surprised when the first thing the young “tech guy” did was sit down with them and find out all about their business processes and bookkeeping. In one case early in my consulting career, due to a chain of odd occurrences at a client’s offices, I ended up being the interim COO of a very non-tech bricks-and-mortar chain for almost a year because I had learned how it ran at a high level. I’m sure a lot of COBOL programmers could do the same.
My work is different now, with tech being just one aspect of it, but I doubt things have changed much with post-COBOL techies who are mostly trained in the way you describe.
Nu surprise that the COBOL runs like a Ferrari. The code may be old, but the computers probably have been replaced with something that run hundreds of times faster than the original ones.
Sometimes worse than ignoring it is separating this. I’ve worked on a lot of projects with teams of business analysts who owned the documentation of processes and requirements. They weren’t always on the same side, and could be the client or part of the tech team. So, that was an added layer - of confusion or clarity, depending on the skills and interaction of the people involved.
This, this, this. If you break down most coding languages into their fundamental syntax you have conditionals, repeat loops, and jumps/traps. Knowing when to use which tools is what is more important.
C isn’t going anywhere for the next few decades either for the same reasons. And that’s not a problem. When you invent the wheel you can spice it up with new rims but you can’t dumb it down into a square, name it after a snake or a type of coffee, and think it’s going to replace everything before it
COBOL debuted in 1959, not 1969!
And 10 years in computer history (yes, even in those times!) is quite a long time, making Grace’s feats even greater.
The linked article does not make that clear, and in fact (wrongly) speaks of “a 50 year old language”.
Beyond the English-like syntax, and logical simplicity, COBOL also has explicit Base 10 arithmetic and numerical types. Remember the “Office Space” movie with the fractions of a penny ? That is quite real, and absolutely important in Banking and Finance. We will discuss the 360 day year in the Banking Calendar some other time.
[quote=“gracchus, post:6, topic:184990”]
clients were surprised when the first thing the young “tech guy” did was sit down with them and find out all about their business processes and bookkeeping
I was one of those “young tech guys” back in the mid to late sixties and spent weeks sitting with “clerks” who were processing insurance claims to learn their procedure and then going back to my desk to flow chart it and code it in COBOL. The insurance company called us programmer analysts. IBM ran schools to teach us the language, but also classes in logic, critical thinking and even some engineering so we would understand the machines that did the computing. I was a young man and am very grateful for the additional education that was available to me from IBM and Blue Cross. It served me the rest of my working life, even though I did not stay in that particular field.
You’re lucky. That training was a benefit I never had when I started my tech career in the early 90s. I came by the business discovery process informally (fortunately critical thinking was a priority at my high school). Most tech people my age were all about the code in the way @philipstorry describes above.
The place I work at has an AS/400 ne iSeries for running it’s HR, payroll, and inventory management systems. We upgraded it to a new mini a couple years ago from a chassis running on a POWER5 processor to a POWER7-based system. (Still running iSeries!) the new chassis? is the BASE MODEL. In fact, most of the cores on it are in an idle/off state, and it’s still heads n tails faster than the hardware it replaced. Unfortunately, we are migrating to cloud-based solutions for these items, which is probably going to be a dumpster fire for a couple months until all the glitches are worked out. Until then, the old guy who knows the system better than almost everyone else there is working in semi-retirement. (I want to say that he’s going to actually retire at the same time the hardware is decommisioned from production use, but that’s probably not the case.)
This is another reason for it’s longevity; it didn’t remain static over all that time but continuously evolved.
I spent the last 10 years or so of my career working with the MicroFocus/Merant implementation of object-oriented COBOL in Windows developing and maintaining commercial business applications.
It was very cool.
My favorite COBOL story: during the great recession, 2007 or so, during the reign of Governor Arnold Schwarzenegger of California, the first thing he did was to lay off all of the retired annuitants to help balance the budget. The 2/3 legislature majority requirement to pass the budget then always was a problem; to force the hand of the legislature, Arnie claimed the ability to lower the pay of all California State Employees to minimum wage until the budget was passed.
That could not be done, though: the payroll system was written in COBOL, and the only programmers they had that could change the system were retired annuitants that had already been laid off.
Back when I was in college (~1980) we did most of our programming in Pascal and Fortran. The CS major still had a COBOL requirement at that time, but I knew enough about COBOL to know I didn’t like it.
So I asked my advisor if I could substitute the extra calculus classes I’d taken for the semester of COBOL. He told me the department didn’t really care if I took COBOL, but the requirement was still there because “wherever you go, you can always find a job doing COBOL”. He said as long as I understood that, if I still wanted to substitute, I could. I did, and never regretted it.
What does Silicon Valley have to do with any of this?
Yeah, the applications from the 70s that still run are great. But acting like it proves a point in a culture war nobody is actually fighting is like saying all new music is trash compared to the greatest hits from back in the day.
a few years back a young computer scientist asked me what languages he should learn to work in the real world. I told him learn both sql and oracle database and cobol languages. Now he’s a $200/hr consultant in his 20s. I should send him an invoice for good advice … haha
Didn’t they have a cobol episode? Nah I believe the OP is going on about how view.js and node.js and python is all garbage compared to cobol- while nodejs is making your internet/online services pretty or “feature rich”, cobol makes it function from end 2 end.
A couple caveats:
- As long as your experience is on a mainframe or AS400.
- As long as your experience is in banking or insurance.
There’s not too much call for experience on other platforms or in other industries, and little to no call for no practical experience.