Why COBOL Isn't the Problem

The problem is maintenance, it&#x27;s a cost center, it doesn&#x27;t directly generate revenue, so it&#x27;s been eliminated.<p>NOBODY is willing to spend money for maintenance on ANYTHING, look at our infrastructure.<p>If it wasn&#x27;t for the FAA making it illegal to not maintain planes, we&#x27;d be seeing the same thing with airlines and their planes.<p>We are seeing this with the Air Force right now, where they are now trying to reverse engineer parts for planes and then 3d print those parts, because no one was willing to spend the money to maintain documentation, maintain vendors, and parts inventory, etc.<p>Software is especially vulnerable to this phenomenon, because it&#x27;s not physical so it&#x27;s considered to be completely fungible, but in fact it&#x27;s even harder to maintain than physical systems.<p>The same way Wall Street rewarded companies that closed factories, and outsourced physical locations, and staff, they&#x27;ve also rewarded companies that have eliminated maintenance.<p>That&#x27;s just the way it is.

There are a few things that the author forgot:<p>- COBOL programs have history. They were changed in &#x27;77 and then the change was reverted in &#x27;79 and then again in &#x27;84. Nobody really remembers why.<p>- COBOL programs do what they do. They do not have specs, but if that&#x27;s the way we have been computing account interests for the last 50 years, they are right. It&#x27;s lawyers documenting them, not the other way around.<p>- COBOL programmers were often meant to be &quot;less&quot; than real programmers. More like junior accountants automating boring procedures, than C wizards. Wizards would not touch COBOL code with a stick. This often shows.<p>This said, the kind of things you could do on a IBM mainframe in the &#x27;70s (virtualization, data safety and efficiency, disaster recovery, even uptime) still run rings around the 90-core boxes with Linux that are in <i>your</i> datacenter racks.

My father has been working in COBOL since the 80s, and his “reference” books are literally a couple of 4” 3 ring binders that he’s assembled over 40 years now of coding.<p>Everytime the bank tries to switch away from COBOL they run into problems ranging from code latency to lack of support for certain features in the new language among other issues thus far.<p>I really don’t know what the banks that run cobol mainframes are going to do as most have ignored the Father Time problem where cobol programmers aren’t getting any younger and the language, in my opinion, is miserable compared to the “magic” of newer era languages.<p>My pops also has made less money then I did as an engineer at a tech co with 3 years experience so banks aren’t valuing the work these folks do very much either.<p>I’ve told my pops he can do consulting once he retires and make a killing because there’s gonna be a major shortage of cobol folks and a massive amount of mainframe code out there that needs maintenance or a transition into a newer era language.<p>Edit: - The author is wrong here<p>“If you need to change old programs, hiring experienced programmers and teaching them COBOL is the cheap part.”<p>There is not a surplus of developers or entry level folks willing to learn cobol over another entry level language, so it’s not cheap and it’s not “easy”.

Also, the program written in COBOL often comes with an ecosystem that can be harder to port than the code itself. Record vs stream oriented filesystems, batch job subsystems, file transfers, block mode terminals, and so on.

&gt; Actually providing the programmers the time and money to make sure<p>In my experience management sidesteps that problem by insisting that you&#x27;re an incompetent fool if you need time and money to accomplish anything.

The article gets it: the problem isn&#x27;t COBOL, the problem is lack of maintenance. The analogy is apt, too: if you never put oil in a car &amp; it fails, the problem is not how the car the built.<p>There are materials for learning COBOL. Here are some materials from the Linux Foundation&#x27;s Open Mainframe project:<p><a href="https:&#x2F;&#x2F;www.openmainframeproject.org&#x2F;projects&#x2F;coboltrainingcourse" rel="nofollow">https:&#x2F;&#x2F;www.openmainframeproject.org&#x2F;projects&#x2F;coboltrainingc...</a><p>And when there was a call last year for COBOL programmers to help some of these aging systems, a lot of people immediately popped up: <a href="https:&#x2F;&#x2F;www.techrepublic.com&#x2F;article&#x2F;ibm-linux-foundation-see-great-response-from-cobol-programmers&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.techrepublic.com&#x2F;article&#x2F;ibm-linux-foundation-se...</a><p>While COBOL has its quirks, it&#x27;s not that hard to learn. It even has some advantages, for example, it has built-in support for fixed-point decimal arithmetic.<p>In general, COBOL is the scapegoat, not the actual problem.

My takeaway: if New Jersey had decided they could save money by just never changing the oil in all their state-owned vehicles they would have been in the same situation as they were when they chose to save money by not maintaining their state-owned software.

I agree to some degree that learning a new language is easy, but learning a new language and understanding its intricacies that could cause issues in a program takes a whole lot longer.<p>It takes a whole lot less time for an experienced COBOL dev to understand a program than it takes for an experienced programmer who just learned COBOL to understand it in my experience.

As I see it that this was a organizational culture failure where he tries to explain it with a technical debt problem.<p>I see the fingerprints of almost feudal organization structure the other aspects when I first read about the New Jerseys problem with COBOL.

&gt; <i>Programming languages are easy to learn</i><p>From our experience with VBA users, this is only true for non-technical (as in STEM background) users when it comes to languages with a close-to-English syntax together with tightly integrated IDE&#x2F;editor. Lua, Python (and occasionally Ruby) are two other languages that are quite &quot;easy&quot; to learn. The curly braces languages? Not so much. Java is especially bad due to its poor error messages and opaque package management&#x2F;build tools. However being easy to learn for the users doesn&#x27;t mean the users are capable of writing good code. We found that code written by amateur users tend to be rather unstructured and incoherent. On the other hand some of the cleanest codebases I have read (from those without formal instruction or experience in software engineering) are by mathematicians and electrical engineers.<p>In terms of tooling Glitch.com and Repl.it are best in for zero-config workflows.

Funky idea:<p>Serverless is Mainframe(COBOL) without transactions

&gt; programming languages are <i>really easy to learn</i><p>&gt; For evidence of how easy it is to learn programming languages, one of the authors of the current paper has, over the course of his life, learned 18 distinct programming languages. His father, a physics professor, claims to have used 20 and 30 programming languages. A quick poll of engineers at Lucid Software showed that this was not unique, with all of the engineers having used at least two programming languages, and the majority having used somewhere between 5 to 20.<p>I&#x27;m curious as to how different the languages that they&#x27;re referring to are.<p>Python, Ruby, Perl, PHP, C, C++, D, and Java are all really similar to each other relative to the differences between them and Coq, Haskell, Lisp, Erlang, Prolog, Io, Spiral, FORTH, or Chapel.

I still wonder what would happen if IBM sold a IBM i for $499 only licensed for developers. It&#x27;s not like the thing really needs high end specs. I wonder how many programmers would go for it on a fluke. Would be good for schools too.

Version control is COBOL&#x27;s problem. Testing mainframe COBOL not in a modern version control is YOLO PITA.

Are the cobol devs from the past the equivalent of the modern day vbs and excel script persons?

To COBOL&#x27;s defence, the compiler generates very fast machine code, so COBOL is all right in my book id est screwing around with the intricacies of that language is okay since the end result is a fast, small program. Based on these two criteria, I conclude that it&#x27;s well worth the effort on the programmer&#x27;s part.