<p>There is more to a CS education than programming. And the goal of a CS program isn't to create programmers for industry. People with a CS undergraduate degree can, on their own, learn enough COBOL to get a job.</p>
<p>But some places will have a course or two. And an Information Systems curriculum is a more hospitable place for it, though the education there isn't focused on programming either.</p>
<p>Note, however, that the language is quite a bit different from what it was in 1970.</p>

CC BY-SA 4.0
2021-04-30T04:15:35.440Z
I do not agree with you. I think we are not doing justice with COBOL....
Free Palestine
CC BY-SA 4.0
2021-04-30T12:30:16.723Z
@TalhaTayyab Which sentence could you possibly disagree with?  I didn't think there was anything even a bit controversial within this answer.
Ben I.
CC BY-SA 4.0
2021-04-30T13:53:39.050Z
@BenI. I agree with  "There is more to a CS education than programming" but still we teach a couple of languages to students. In some places they teach 3 - 4 languages a part from Data Structures, Design of Algorithms, Automata, Compilers, etc.  COBOL is ignored altogether by one and all.
Free Palestine
CC BY-SA 4.0
2021-04-30T14:21:40.487Z
Cobol might be discussed in a programming languages course.
Buffy
CC BY-SA 4.0
2021-04-30T20:29:12.357Z
+1 for @Buffy's comment
Free Palestine
CC BY-SA 4.0
2021-04-30T20:44:52.860Z
Don't be too hasty. I said "discussed", not taught. The normal purpose of the programming languages course isn't "examples of..." but "principles of...". I once taught COBOL to information systems students, actually. More recently, I was the professor for both programming languages and compiler implementation.
Buffy
CC BY-SA 4.0
2021-05-01T18:21:35.883Z
"And the goal of a CS program isn't to create programmers for industry." I sympathize with this. But let's acknowledge this is a prescriptive statement. Not a descriptive one. Historically ppl have differed on what the mission of higher education is. Some c it as something that should cater to the imperatives of the market. While others think it should stand at some remove from those needs. U can c these tensions at work in books like Veysey's "The Emergence of the Am. Univ." in which the ideal of "utility" was lauded in community and land grant colleges but less so at trad 4 year univ.
Luke
CC BY-SA 4.0
2021-05-02T12:12:18.380Z
I also agree with your first sentence, but if people emerge from four years of an expensive cocoon unable to get work, something is wrong. I graduated in a recession and it took inordinately long to find any job. This is inappropriate for human worth and dignity, but I guess that is not anyone's' job. Yet. Such a position - maximizing human potential - should be. Universities are not doing that, and maybe they can't. But revolutions are repeatedly fought over this point and it persists.
Scott Rowe
CC BY-SA 4.0
2021-05-23T01:08:47.130Z
"And the goal of a CS program isn't to create programmers for industry" -- even if it was, it's not obvious that educating everyone in COBOL would be a good way to fufill the industry's needs on the whole. Even with a shortage of engineers in the mainframe niche, it's still a niche, and training people in COBOL isn't useful to most roles. Hop on any job board and it's predominantly modern technologies. Necessity is the mother of invention: if the COBOL shortage was truly as severe as advertised, we'd probably already see these classes.
ggorlen
CC BY-SA 4.0
2021-04-29T23:10:14.373Z
2021-04-29T23:10:14.373Z
Buffy
<p>I keep returning to the idea that code should be simple and made to be thrown away. Build once, use a while, then let someone else be useful, creative, necessary, helpful... Let people build back better with something that didn't exist the first time around.</p>
<p>So to me, this clinging to ancient code is a mentality of fear and scarcity, which we would be better off without. If it is too complex, simplify it and live with a simpler solution. This seems really &quot;First World Problem&quot; to me. There are a lot of programmers in other parts of the world, who need work.</p>

CC BY-SA 4.0
2021-05-02T11:30:52.363Z
Enterprise systems don't work like that, actually. This is the COBOL "problem space".
Buffy
CC BY-SA 4.0
2021-05-02T12:05:52.243Z
@Buffy That does indeed seem like a *problem*. We should never be so attached to something or so dependent on it that we are unable to replace it with something better. I would say that Enterprises ought to see such painful reliance as an "existential risk" and correct it as fast as they can. If you are not using your computer to get to the Moon, you will not die if it fails, and so you should be able to fix it without it becoming a crisis. Unless your computer is driving the vehicle that is taking you to the hospital, I guess... Every system has an Achille's Heel (said Goedel).
Scott Rowe
CC BY-SA 4.0
2021-05-02T12:08:30.837Z
Systems are cheap these days, so just have multiple ones, and when one springs a leak, switch it off and the others keep going while you create yet another. Evolution comes to the world of enterprise software.
Scott Rowe
CC BY-SA 4.0
2021-05-03T12:05:44.360Z
Sorry, but no. NO. Why would a company discard an asset that they spent millions to develop and refine? COBOL is very stable and its quirks are known. Python is cool, but evolving, with potential faults yet to be discovered. Why would a company discard hundreds of cumulative experience-years in a technology for the "next new thing".  The problem isn't with COBOL as much as it is with the fact that the experts with that accumulated knowledge are retiring/dying with no replacement in sight. I'd guess IBM has thousands of experience-years invested in COBOL. Maybe another order of magnitude more.
Buffy
CC BY-SA 4.0
2021-05-04T00:08:07.937Z
@Buffy, just look at Netscape (Remember them?  Their browser was *the* browser in use, and they had a nice collection of other software offerings.). They decided sometime in the '90s to rewrite Netscape from scratch, as they considered (probably with good reasons) that it was too full of cruft. Never finished the rewrite, the company went under in large part because of the effort diverted into the rewrite away from bug fixes/new product development.
vonbrand
CC BY-SA 4.0
2021-05-05T21:25:58.900Z
@vonbrand I am thinking that there is very little new product development going on with COBOL systems that are almost as old as I am. If there are still bugs in software that old, it would be mysterious.
Scott Rowe
CC BY-SA 4.0
2021-05-05T21:30:04.093Z
@Buffy It seems to me that the absolutely vital stuff should be in basically platform-independent form, and should not really be changing/ So OK, it could stay in COBOL, but 95% of the code is a wrapper that could be migrated, modified, redeveloped, etc.  That is what I would do. Leave the engine alone but change the rest of the car as much as you want. The accumulated knowledge should be expressed in something that doesn't need to change. Can we say Domain Specific Language? Sure. Martin Fowler has proposed that since I was first programming, and I got the idea from people who taught me.
Scott Rowe
CC BY-SA 4.0
2021-06-25T18:17:51.040Z
@ScottRowe, most "maintenance" isn't "fixing bugs", it is porting to the new machine, connecting to this new-fangled "web" thingy, replacing the backend that worked with database X to use database Y, some law changes and the way some quantity is computed has to be updated.
vonbrand
CC BY-SA 4.0
2021-05-02T02:11:29.753Z
2021-05-02T02:11:29.753Z
Scott Rowe
<p>Programmers are free to pick up the language, and there are plenty of resources out there to help anyone who wishes to learn COBOL to do so.</p>
<p>I could imagine a programmer boot camp that focused on COBOL, and it might be in the interest of the Big Banks to create just such an institution.  However, the mission of a <em>computer science</em> program is quite different from the mission of a coding boot-camp.  Computer Science programs teach the core concepts of the field of computer science.  There are no important, underlying CS concepts that are best taught in COBOL, and this makes it a poor choice for most of what we do. While nods can be made to industry in language choice, computer science is what we are here to teach.</p>
<p>The reason that there are so many institutions that still rely on COBOL is because they have a tremendous amount invested in that architecture from decades ago when the language really was still in use.</p>
<p>However, there are also important reasons that the language is dying.  For instance take a look at <a href="https://www.quora.com/What-are-the-reasons-for-the-death-of-COBOL-as-a-programming-language" rel="nofollow noreferrer">this quora post by the user &quot;Jack Menendez&quot;</a>:</p>
<blockquote>
<p>The assumption Dead is a matter of definition. However, the reasons why new applications are never written in COBOL is:</p>
<p>COBOL has a special type called a Packed Decimal that is a fundamental type for a mainframe. COBOL code and databases used by COBOL are full of Packed Decimals. To a mainframe Packed Decimal works kind of like an integer on intel but it is a kind of decimal. So there are machine level instructions on the mainframe that can deal with the Packed Decimal add/subtract/Div etc. The intel architecture does not have any idea what Packed Decimals are so COBOL compilers that target Intel must create code that simulates them. COBOL runs much slower on the Intel architecture for this reason and can create binaries that are relatively large.</p>
<p>COBOL programs are non-reentrant by their nature. In fact the code and internal data fields on the mainframe normally occupy the same contiguous piece of storage. This makes it hard to use COBOL in environments such as application servers that expect reentrant code. Application servers ported to the mainframe typically cannot use COBOL.</p>
<p>COBOL code has a syntax that is not like other languages, writing &quot;Hello World&quot; in COBOL is kind of an ordeal for a beginner.</p>
</blockquote>
<p>The increased salary for COBOL programmers is reasonable since there needs to be a way to reward programmers who take the time to learn languages that have little applicability elsewhere.  It is also part of the expense for maintaining dated software on decaying architectures.</p>
<p>Every year, more and more of this COBOL code is being replaced as the maintenance costs go up and the ability to expand its functionality decreases.  And this is for the good!  While there will always be room for people who truly love the language to keep the flame alive, the large base of industry should be where people can be efficient, and that is no longer in COBOL.</p>

CC BY-SA 4.0
2021-05-01T19:30:37.007Z
*"there are also important reasons that the language is dying..."* - the listed reasons turned out to be less than compelling. The efficient handling of decimals by Cobol (and the underlying mainframe architecture, compared to Intel) is surely one of the reasons it *is still* used, rather than a reason why it is ceasing to be used.
Steve
CC BY-SA 4.0
2021-05-04T00:03:24.450Z
@Steve, today's "enterprise applications" run on oversized PCs.
vonbrand
CC BY-SA 4.0
2021-04-30T12:59:56.077Z
2021-04-30T12:59:56.077Z
Ben I.
<p>It is a well-known fact that we have a shortage of COBOL programmers. Why we do not re-introduce COBOL in our curriculum for the Undergraduate and Graduate Students?</p>
<p>I know some schools are teaching mainframes but, they are very limited.</p>
<p><a href="https://cacm.acm.org/news/244370-cobol-programmers-are-back-in-demand-seriously/fulltext#:%7E:text=Experienced%20Programmer%20Shortage&amp;text=Although%20a%20few%20universities%20still,it%20today%20is%20extremely%20small.&amp;text=In%20the%20age%20of%20apps,at%20retiring%20their%20mainframe%20systems" rel="nofollow noreferrer">https://cacm.acm.org/news/244370-cobol-programmers-are-back-in-demand-seriously/fulltext#:~:text=Experienced%20Programmer%20Shortage&amp;text=Although%20a%20few%20universities%20still,it%20today%20is%20extremely%20small.&amp;text=In%20the%20age%20of%20apps,at%20retiring%20their%20mainframe%20systems</a>.</p>
<p>Since all the workforce for the COBOL is aging and getting retired. Banks, insurance, retail, airline, etc. are still using COBOL.</p>
<p><a href="https://www.howtogeek.com/667596/what-is-cobol-and-why-do-so-many-institutions-rely-on-it/" rel="nofollow noreferrer">https://www.howtogeek.com/667596/what-is-cobol-and-why-do-so-many-institutions-rely-on-it/</a></p>
<p>IBM reported, &quot;As late as 2017, 92 of the top 100 banks still used mainframes for their core businesses.&quot;</p>
<p><a href="https://www.tpr.org/technology-entrepreneurship/2019-05-23/how-cobol-still-powers-the-global-economy-at-60-years-old" rel="nofollow noreferrer">https://www.tpr.org/technology-entrepreneurship/2019-05-23/how-cobol-still-powers-the-global-economy-at-60-years-old</a></p>
<p>Also, fresh graduates are getting a salary of $75K or above for COBOL. All this being said, is there a way to revive this beautiful language through our students?</p>

CC BY-SA 4.0
2021-05-01T19:37:12.457Z
*"It is a well known fact that we have shortage of COBOL programmers"* - is it? The lobby groups of all industries constantly claim to have a shortage of workers - it doesn't usually reflect the reality. Usually they are just holding out the begging bowl, wanting the state to cover training costs or ramp up immigration from low-wage economies.
Steve
CC BY-SA 4.0
2021-05-02T05:29:30.223Z
@Steve unfortunately a lot of COBOL coders passed away in Covid and many got retired.. there is a shortage....indeed..
Free Palestine
CC BY-SA 4.0
2021-05-02T07:58:26.303Z
Trust me, it's the same dismal chorus we hear every time the employers have to pay above minimum wage or have to plan their workforce needs more than a couple of months ahead.
Steve
<programming>
COBOL programmers
# COBOL programmers

(Asked by: username_0 on 2021-04-29)

It is a well-known fact that we have a shortage of COBOL programmers. Why we do not re-introduce COBOL in our curriculum for the Undergraduate and Graduate Students?

I know some schools are teaching mainframes but, they are very limited.

[https://cacm.acm.org/news/244370-cobol-programmers-are-back-in-demand-seriously/fulltext#:~:text=Experienced%20Programmer%20Shortage&text=Although%20a%20few%20universities%20still,it%20today%20is%20extremely%20small.&text=In%20the%20age%20of%20apps,at%20retiring%20their%20mainframe%20systems](https://cacm.acm.org/news/244370-cobol-programmers-are-back-in-demand-seriously/fulltext#:%7E:text=Experienced%20Programmer%20Shortage&text=Although%20a%20few%20universities%20still,it%20today%20is%20extremely%20small.&text=In%20the%20age%20of%20apps,at%20retiring%20their%20mainframe%20systems).

Since all the workforce for the COBOL is aging and getting retired. Banks, insurance, retail, airline, etc. are still using COBOL.

<https://www.howtogeek.com/667596/what-is-cobol-and-why-do-so-many-institutions-rely-on-it/>

IBM reported, "As late as 2017, 92 of the top 100 banks still used mainframes for their core businesses."

<https://www.tpr.org/technology-entrepreneurship/2019-05-23/how-cobol-still-powers-the-global-economy-at-60-years-old>

Also, fresh graduates are getting a salary of $75K or above for COBOL. All this being said, is there a way to revive this beautiful language through our students?

**Tags:** programming

> **Comments:**
> **username_1**: *"It is a well known fact that we have shortage of COBOL programmers"* - is it? The lobby groups of all industries constantly claim to have a shortage of workers - it doesn't usually reflect the reality. Usually they are just holding out the begging bowl, wanting the state to cover training costs or ramp up immigration from low-wage economies.  
> **username_0**: @username_1 unfortunately a lot of COBOL coders passed away in Covid and many got retired.. there is a shortage....indeed..  
> **username_1**: Trust me, it's the same dismal chorus we hear every time the employers have to pay above minimum wage or have to plan their workforce needs more than a couple of months ahead.  

---

## 3 answers

### Answer by username_3 on 2021-04-30. Score: 4

Programmers are free to pick up the language, and there are plenty of resources out there to help anyone who wishes to learn COBOL to do so.

I could imagine a programmer boot camp that focused on COBOL, and it might be in the interest of the Big Banks to create just such an institution. However, the mission of a *computer science* program is quite different from the mission of a coding boot-camp. Computer Science programs teach the core concepts of the field of computer science. There are no important, underlying CS concepts that are best taught in COBOL, and this makes it a poor choice for most of what we do. While nods can be made to industry in language choice, computer science is what we are here to teach.

The reason that there are so many institutions that still rely on COBOL is because they have a tremendous amount invested in that architecture from decades ago when the language really was still in use.

However, there are also important reasons that the language is dying. For instance take a look at [this quora post by the user "Jack Menendez"](https://www.quora.com/What-are-the-reasons-for-the-death-of-COBOL-as-a-programming-language):

> The assumption Dead is a matter of definition. However, the reasons why new applications are never written in COBOL is:
>
> COBOL has a special type called a Packed Decimal that is a fundamental type for a mainframe. COBOL code and databases used by COBOL are full of Packed Decimals. To a mainframe Packed Decimal works kind of like an integer on intel but it is a kind of decimal. So there are machine level instructions on the mainframe that can deal with the Packed Decimal add/subtract/Div etc. The intel architecture does not have any idea what Packed Decimals are so COBOL compilers that target Intel must create code that simulates them. COBOL runs much slower on the Intel architecture for this reason and can create binaries that are relatively large.
>
> COBOL programs are non-reentrant by their nature. In fact the code and internal data fields on the mainframe normally occupy the same contiguous piece of storage. This makes it hard to use COBOL in environments such as application servers that expect reentrant code. Application servers ported to the mainframe typically cannot use COBOL.
>
> COBOL code has a syntax that is not like other languages, writing "Hello World" in COBOL is kind of an ordeal for a beginner.

The increased salary for COBOL programmers is reasonable since there needs to be a way to reward programmers who take the time to learn languages that have little applicability elsewhere. It is also part of the expense for maintaining dated software on decaying architectures.

Every year, more and more of this COBOL code is being replaced as the maintenance costs go up and the ability to expand its functionality decreases. And this is for the good! While there will always be room for people who truly love the language to keep the flame alive, the large base of industry should be where people can be efficient, and that is no longer in COBOL.

> **Comments:**
> **username_1**: *"there are also important reasons that the language is dying..."* - the listed reasons turned out to be less than compelling. The efficient handling of decimals by Cobol (and the underlying mainframe architecture, compared to Intel) is surely one of the reasons it *is still* used, rather than a reason why it is ceasing to be used.  
> **username_7**: @username_1, today's "enterprise applications" run on oversized PCs.  

---

### Answer by username_2 on 2021-04-29. Score: 1

There is more to a CS education than programming. And the goal of a CS program isn't to create programmers for industry. People with a CS undergraduate degree can, on their own, learn enough COBOL to get a job.

But some places will have a course or two. And an Information Systems curriculum is a more hospitable place for it, though the education there isn't focused on programming either.

Note, however, that the language is quite a bit different from what it was in 1970.

> **Comments:**
> **username_0**: I do not agree with you. I think we are not doing justice with COBOL....  
> **username_3**: @TalhaTayyab Which sentence could you possibly disagree with?  I didn't think there was anything even a bit controversial within this answer.  
> **username_0**: @BenI. I agree with  "There is more to a CS education than programming" but still we teach a couple of languages to students. In some places they teach 3 - 4 languages a part from Data Structures, Design of Algorithms, Automata, Compilers, etc.  COBOL is ignored altogether by one and all.  
> **username_2**: Cobol might be discussed in a programming languages course.  
> **username_0**: +1 for @username_2's comment  
> **username_2**: Don't be too hasty. I said "discussed", not taught. The normal purpose of the programming languages course isn't "examples of..." but "principles of...". I once taught COBOL to information systems students, actually. More recently, I was the professor for both programming languages and compiler implementation.  
> **username_4**: "And the goal of a CS program isn't to create programmers for industry." I sympathize with this. But let's acknowledge this is a prescriptive statement. Not a descriptive one. Historically ppl have differed on what the mission of higher education is. Some c it as something that should cater to the imperatives of the market. While others think it should stand at some remove from those needs. U can c these tensions at work in books like Veysey's "The Emergence of the Am. Univ." in which the ideal of "utility" was lauded in community and land grant colleges but less so at trad 4 year univ.  
> **username_5**: I also agree with your first sentence, but if people emerge from four years of an expensive cocoon unable to get work, something is wrong. I graduated in a recession and it took inordinately long to find any job. This is inappropriate for human worth and dignity, but I guess that is not anyone's' job. Yet. Such a position - maximizing human potential - should be. Universities are not doing that, and maybe they can't. But revolutions are repeatedly fought over this point and it persists.  
> **username_6**: "And the goal of a CS program isn't to create programmers for industry" -- even if it was, it's not obvious that educating everyone in COBOL would be a good way to fufill the industry's needs on the whole. Even with a shortage of engineers in the mainframe niche, it's still a niche, and training people in COBOL isn't useful to most roles. Hop on any job board and it's predominantly modern technologies. Necessity is the mother of invention: if the COBOL shortage was truly as severe as advertised, we'd probably already see these classes.  

---

### Answer by username_5 on 2021-05-02. Score: -1

I keep returning to the idea that code should be simple and made to be thrown away. Build once, use a while, then let someone else be useful, creative, necessary, helpful... Let people build back better with something that didn't exist the first time around.

So to me, this clinging to ancient code is a mentality of fear and scarcity, which we would be better off without. If it is too complex, simplify it and live with a simpler solution. This seems really "First World Problem" to me. There are a lot of programmers in other parts of the world, who need work.

> **Comments:**
> **username_2**: Enterprise systems don't work like that, actually. This is the COBOL "problem space".  
> **username_5**: @username_2 That does indeed seem like a *problem*. We should never be so attached to something or so dependent on it that we are unable to replace it with something better. I would say that Enterprises ought to see such painful reliance as an "existential risk" and correct it as fast as they can. If you are not using your computer to get to the Moon, you will not die if it fails, and so you should be able to fix it without it becoming a crisis. Unless your computer is driving the vehicle that is taking you to the hospital, I guess... Every system has an Achille's Heel (said Goedel).  
> **username_5**: Systems are cheap these days, so just have multiple ones, and when one springs a leak, switch it off and the others keep going while you create yet another. Evolution comes to the world of enterprise software.  
> **username_2**: Sorry, but no. NO. Why would a company discard an asset that they spent millions to develop and refine? COBOL is very stable and its quirks are known. Python is cool, but evolving, with potential faults yet to be discovered. Why would a company discard hundreds of cumulative experience-years in a technology for the "next new thing".  The problem isn't with COBOL as much as it is with the fact that the experts with that accumulated knowledge are retiring/dying with no replacement in sight. I'd guess IBM has thousands of experience-years invested in COBOL. Maybe another order of magnitude more.  
> **username_7**: @username_2, just look at Netscape (Remember them?  Their browser was *the* browser in use, and they had a nice collection of other software offerings.). They decided sometime in the '90s to rewrite Netscape from scratch, as they considered (probably with good reasons) that it was too full of cruft. Never finished the rewrite, the company went under in large part because of the effort diverted into the rewrite away from bug fixes/new product development.  
> **username_5**: @username_7 I am thinking that there is very little new product development going on with COBOL systems that are almost as old as I am. If there are still bugs in software that old, it would be mysterious.  
> **username_5**: @username_2 It seems to me that the absolutely vital stuff should be in basically platform-independent form, and should not really be changing/ So OK, it could stay in COBOL, but 95% of the code is a wrapper that could be migrated, modified, redeveloped, etc.  That is what I would do. Leave the engine alone but change the rest of the car as much as you want. The accumulated knowledge should be expressed in something that doesn't need to change. Can we say Domain Specific Language? Sure. Martin Fowler has proposed that since I was first programming, and I got the idea from people who taught me.  
> **username_7**: @ScottRowe, most "maintenance" isn't "fixing bugs", it is porting to the new machine, connecting to this new-fangled "web" thingy, replacing the backend that worked with database X to use database Y, some law changes and the way some quantity is computed has to be updated.  

---

