Legacies | The COBOL Chronicles

  |  Compiler Team  
Sviluppo professionale
Storia della tecnologia

Compiler • • The COBOL Chronicles | Compiler: Legacies

The COBOL Chronicles | Compiler: Legacies

About the episode

It has become the programming language underneath some of the most important industries in the world, but the community surrounding COBOL is aging, and companies are hungry for newer innovation. COBOL has stood the test of time, but what is its place among newer generations of technologists?

Want to dive deeper into the history of COBOL? Check out the Command Line Heroes episode, “The Infrastructure Effect”.

Compiler team Red Hat original show

Iscriviti

Subscribe here:

Listen on Apple Podcasts Listen on Spotify Subscribe via RSS Feed

Trascrizione

In terms of when you ask how widespread it is, there are somewhere on the order of three digit billions of lines of COBOL source code in production right now in the world. Common business oriented language, or COBOL, has been around since the 1960s. It underpins a lot of the technology we use every day. Virtually every credit card transaction, every ATM transaction (because that's what the bank has) that ATM transaction eventually connects to, everything from printing your statement every month or making a PDF of it for you to download, to just all the routine business that takes place. If you work in IT, you may already know the history of COBOL, its mass adoption over time, and its prevalence—but what's behind its staying power? And with all of the different newer programming languages out there, should we still be learning it? This is Compiler, an original podcast from Red Hat. I'm Brent Simoneaux. And I'm Angela Andrews. We go beyond the buzzwords and jargon, and simplify tech topics. Today we are talking about COBOL. Let's kick it to producer Kim Huang. She's ready to get us started. For this episode I spoke with two people, Scott Spurlock, who you just heard, and Jesus Freire. Scott is a software engineer at IBM. My background has been almost entirely software engineering in COBOL, and the mainframe has been the bulk of it, but other platforms, other languages too. He specializes in legacy modernization and mainframes. Mainframes are large servers built for processing large amounts of data. To understand COBOL and its long history, you need to understand the mainframe where the programming language lives. COBOL does what it was designed to do. It is not producing video graphics. It's not exciting. It is designed to crunch massive numbers of huge values very quickly, very accurately, very securely, and economically at the same time. That's right, these mainframes are built to process data for the purposes of transactions and a wide variety of them. So in the 1960s, what we know as the tech industry was still coming together, this was revolutionary for a lot of reasons. I spoke with Jesus to find out more. He's a distinguished engineer and the CTO of Global Banking for IBM's consulting arm. He's based in Madrid. When COBOL was created, the main type of processing was batch processing, and for that COBOL is super fantastic. So on the mainframe, batch processing where software runs different jobs in groups or batches—think very high volume, repetitive tasks like deposits and debits in a person's bank account, for example—common business processes that take place all the time. The banks were one of the first adopting IT technology for automation of the back office processes in the 1950s and the 1960s, and still many of the systems are running because they provide good performance, they have a very good functional quality, and they are very secure. They would have to be secure because COBOL was created by the U.S. government under a mandate for the creation of a common business language. A bunch of people got together, you might recognize a name or two in there if you look up the history online, Grace Hopper, a lot of these great minds got together and wanted to build a common business language for both governmental organizations and also private companies to be able to build things that were in that same kind of language, everybody could understand what everybody else was doing, right? The thing is, COBOL was only supposed to exist as a stopgap, a temporary solution until another agreed upon language was created. But that temporary solution allowed portability of programs, it was very easily understood and therefore easily adopted by developers, and when computer manufacturers started building compilers for COBOL, it saw mass adoption. So COBOL over time became the programming language of banking for the entire world. But why though? There's other programming languages out there, this was supposed to be just a temporary solution. Why did COBOL become so popular? The B in COBOL, the C-O-B-O-L, B from business, it's very oriented to business and doing the things that a bank needs, like automatic calculation, stored and recovered data—it's very efficient for doing that. And also it was by then a language that in some way was resembling English. Most programmers back then working on a mainframe didn't have a computer science degree, because they didn't really exist yet, at least not the way they exist today, right? Yeah. So the syntax for a common business language had to be easy for everyone to learn. COBOL delivered on that. And after a while, it wasn't just within the banking industry where one could find COBOL. And so that probably was the reason that COBOL has this long history of engagement with banking, but other industries like insurance or healthcare or transportation that started by then also to implement information systems were using it as well. Remember, this is transactional data, so think about all those different transactions you make over the course of a single day. Buying a plane ticket, that's COBOL, buying a ticket on the train to go to work every day, that's probably COBOL, if you are going online and checking your benefits when you're looking at your health insurance, COBOL again. It was revolutionary and incredibly efficient for the time. Years have passed, it's been a while since the 1960s, and COBOL's popularity has waned—and some say its relevance has too. Jesus has some ideas as to why that is. Maybe you can remember this black and green screen that now evolved to new user interfaces—for that, it is not the most suitable programming language. It's that black and green screen, like the Matrix kind of—you remember the movie The Matrix? It has the green letters on the black, that's what COBOL looks like, and it's kind of the purest form if we're talking about people who are working directly on these mainframes. Are those CRT screens, is that what they're called? I think so, yeah. Okay. There's more to the story though. I can't get agreement on an exact number, but most industry experts I've talked to for this episode put the average age of the COBOL programmer at 53. That is a little higher than I would expect a programmer to . . . Angela's giving me eyes. I want to hear what you're about to say sir. I'm going to stay out of this. I was going to say that is a higher average than I was expecting—average than I was expecting. Emphasis on average, Angela. Okay. Duly noted. It has gotten to the point though where larger companies and government organizations are starting to sound the alarm. The adopter base used to be sprawling, it's now dwindled. Specialists are aging out of the workforce and the community around COBOL is disappearing. With a number of other programming languages there are more, let me say vivid or active ecosystems, and that ecosystem does not exist so much in COBOL. Some people make the argument that this was a long time coming, after all, COBOL wasn't supposed to be permanent anyway. Oh yeah. And it's time for the tech industry to move on with something new—newer languages, newer interfaces, newer development environments. But here's the rub, this is all coming at a time where there is an unprecedented push for modernization, whether it's the Internal Revenue Service here in the [United] States or the National Healthcare System or NHS in the UK, governments are trying really hard to move their legacy system to the latest and greatest. At the same time, and this is no surprise to you Brent, or you Angela, migration work isn't simple, nor is it cheap. No, ma'am. So sometimes decisionmakers are caught between building for the future and maintaining what's still running. Angela, can you talk us through what exactly makes this challenging and expensive? Well, if we're looking at how efficient a program is or the hardware that it's running on, or its ability to be portable, if it's lacking where I can't run it, but only on this particular piece of hardware or it's not scalable or it requires this really high level of understanding and specialized skillset to be able to write new features, to maintain it, to do all those things—it becomes very expensive when there is not this community around it that's not rallying for it. I think the reason a lot of people get into specific programming languages is because the communities are so vibrant and so vocal, and you don't hear that about COBOL. So people aren't flocking to become COBOL programmers. So that's why you say that average age is 53 years old because anyone who's trying to learn how to code is not looking for COBOL as their first language. They're going to be looking for stuff, the new hotness, like what is everyone else talking about? So that's really a huge part of it. Its lack of portability, its lack of scalability, its lack of subject matter experts. You can't continue down this pike because technology is going in the direction of microservices, smaller, modular—this is the exact opposite of that. Exactly. And this is kind of a theme that I'm sensing in this series is there's a little bit of a conflict or a tension there between the newness and the oldness. Yes. Yeah, it is. I can't explain it. I think they're saying that this language was a temporary fix for some issue— Yes. That was happening back in the day, and apparently it solved that issue so well that it basically became a standard for business programming. And that's not a small feat to become so prevalent and such a huge part of so many transactional verticals, be it banking or healthcare, that's no small feat. So I get it, it's so embedded, but how do we remove that? How do we move from COBOL to say a Python or COBOL to a JavaScript or COBOL to Spring Boot? How do we do these things? And that's probably where the migration issue is coming. How do you go from COBOL to any modern programming language? Especially in industries like for example, travel and transportation and banking, where the amount of transactions that are going on are constant all over the world, all at once. Within seconds, there's thousands upon thousands upon thousands of transactions going on. And then you tell this company, "Well, we're going to migrate away from COBOL and from this language and this system that already works and does the job well to this new thing, but that requires downtime." Can you imagine telling a company that you're going to have some downtime, people that are trying to buy plane tickets just aren't going to be able to buy them for, I don't know, a few hours. That's not a conversation that I would like to have with someone. And we talk about, this thing happens in modern application development, blue-green deployments where you're running something that's a little bit older, you have this new deployment that has this new feature set and whatever, and you can have some workloads moving in one direction, you can stop some traffic from going to one deployment, test it out, see how it goes. That is where we would like to see something like this, but where is the blue-green deployment in COBOL? How would you do something like this? We can't have downtime. We can't have downtime in healthcare and airlines because the world would stop. So it's clear why COBOL became so prominent, but things have changed in IT—dramatically. There are other languages and other hardware capabilities beyond the mainframe. With all of this in mind, is COBOL still worth learning? We'll discuss that next. At first, I wanted to know how hard is it to learn COBOL? According to Jesus, it isn't so rough, and that's by design. Remember COBOL came along at a time where programmers didn't necessarily have a formal education in their profession. Now that's interesting you say that because my mom started learning COBOL in college. Wow. Yes. And she said back in '78, she remembered programming in COBOL, and her analogy was, it's just like writing a love letter, you say what you mean, and that's it. It's very clear, very concise. And she also said something that I thought was hysterical because if you ever met my mom, this sounds like something she would say. Apparently she was like, when you're in programming class and you're writing notes or whatever, and my mom, she is a pretty smart cookie, people would always want to get her answers or look at her code and do like this and do like that. And so my mom, she said she would write notes and then she would make wrong notes like, "This is not the right thing, but I'm going to write them anyway." And then after class, she would throw them in the trash because she knew someone probably was going to pick out her notes because she was smart, people were always asking her questions, and she just laughed uncontrollably reciting this story. So mom, if you're listening, you can laugh some more, because I was just like, "Oh my God, why is she still laughing?" It was just—she tickled herself. What a prankster. My mom is definitely the prankster. So when you're talking about it being an easy language, I'm not sure what year of college she was in, but it came along and she said, it's like writing a love letter, it's just clear and concise and to the point. That's really interesting especially considering that COBOL isn't taught in universities that much anymore, and it's certainly not an entire class. I'm going to bring back Scott. He's saying the same thing. COBOL ceased to be taught in colleges about the time my career was starting in the mid-1980s, and I wound up learning it in a technical college after I graduated from a four-year college. Angela, what's your experience with COBOL? Did you learn it during your education? I need to know who wrote that prompt. [Laughing.] How old do you think I am? Seriously? No, hey, listen, my husband is 43 and he had at least one, I think one class where part of the class they taught him COBOL and he just graduated this year. So— What! It's not a reference to age or anything, it's just an honest question of what your experience with COBOL has been. For the record 53, I think quite young, quite young. Brent is desperately trying to recover. He's climbing himself up out of that hole. Climbing it. So my experience with COBOL is that I've never written anything in COBOL other than maybe as a kid, because I was so inquisitive reading my mom's notes. I read everything when I was a kid. Also, when I was in college, we just learned that COBOL was a language, and that's what we learned about it. We learned what it was, what it wasn't, and where it came from and the history of it, but nothing to the extent of, let's write some COBOL code. Never. That hasn't happened for me. There is this perception—to your point, Angela—of COBOL just being something you read about in a history book. In technology, newer can be conflated with better and with the abundance of different languages that IT professionals can and do choose to learn, something as venerated as COBOL can suffer from an image problem. Here's Scott again. I think there's a great deal of misperception in that, in the first place if you're going to call something outdated and a dinosaur, tell me why. Provide the specifics, support your argument logically, and if what you're doing in the language is the same thing every other language does, you set variables to values. Okay, what's outdated, what's antiquated about that? And ah-ooh. Right, exactly. Yeah. Mic drop. Yeah. Exactly. Okay. Yes, that was a great response. It was. How do you feel about it? I mean, it does its job and it does its job apparently very well, so much so that these important systems are still using it. I mean, we know it's difficult to move away from it, but it does its job very well, and you can't take that away from the language. The fact that it's outdated, well, it's in use right now. What exactly makes it outdated? Because no one's teaching it in college? Maybe because people who know the language are actually working professionals and not teaching. There's a lot of reasons it's not the new flashy thing. Again, it doesn't have that huge community around it. You don't hear, maybe it doesn't have a subreddit, I don't know, but— No, it definitely has a subreddit. But to your point, it does the same thing every language does. Yeah. Full stop. And you really can't argue with that. If the popularity is the litmus test, then we know that that is not a good test to compare anything. But there is a struggle out there to find COBOL programmers. So I feel like there's some kind of piece of the puzzle that's missing for a lot of people. I asked Scott and Jesus how interest in COBOL can be fostered. Scott is taking a proactive role, he actually trains people who are interested in learning COBOL. I honestly believe that a cohort of young people, younger people, twenties, who write software because they love software, would have an absolute blast with it. That's interesting. It is very interesting. I found Scott through a bunch of boards that were created by a couple of different organizations, including IBM, to foster more interest in COBOL and to get more programmers interested in learning COBOL, and he was one of the people who was very vocal about his experiences. What is the job market like for a COBOL programmer today? If every person I've talked to, not just Scott says the same thing, if you know COBOL, you'll never not have a job. That's where the money resides, okay. Well, that is so interesting because you think about what's old is new again for so many different things. I mean, fashion and hairstyles and television shows, there's always this resurgence of something that comes along that younger people can gravitate toward. I think COBOL has a marketing issue. Absolutely. Maybe we need to figure out how to better market. There is definitely space for better marketability and better innovation. Scott says a community could coalesce around COBOL and bring in newer ideas, new interfaces for people to work on or new development environments for COBOL. What the developers are seeing is no longer that horrible 24 x 80 green on black screen that we associate with old school mainframe. And that could help build a new generation of practitioners. I'm all for it. I mean, I think we need to get Scott in the room with some of these popular DevRel [developer relations] types who are building these online cohorts of bootcamps for people to learn how to code and getting them in there, and again, building a community around how amazing COBOL is and has been for so many years. Scott is onto something, and again, if he markets this well or gets a good marketing team around, I could see COBOL coming into the next couple of years as an up and coming programming language for new folks. If you told me that I could get a job, get paid a really good amount of money for writing the equivalent of a love letter, I'm in. You know what mom, come on out of retirement, make it happen, okay. I mean, why not? Because it sounds as if that there are plenty of jobs out here that would be willing to provide this service. Again, if you're talking about the folks aging out, that's with any profession, you need to bring people in to help innovate and to help pull this along because it doesn't look like it's going anywhere. And it seems like there's something, like in listening to what Scott was saying and then also hearing about how your mom described it, Angela, there's something that feels very—this is going to sound a little strange, but a little poetic or human or just something that's really enjoyable about the language in writing it, like the syntax. There's nothing better than writing a syntactically beautiful language where I said what I said, I'm putting it in code, this is exactly what I mean, and it runs. We would all be so lucky to learn a programming language that is as forgiving, and maybe forgiving is not the right word, but very descript. This is what I want to do, there's little room for nuance, and it could be this, it could be that. This seems like one of those things where this is what I'm typing and this is exactly what I mean. There's less room for error in that way. Absolutely. Let's do it. Scott and Jesus shared with me what they learned over the course of their careers about legacy languages like COBOL compared to newer ones. Over the years, we have seen a lot of innocent babies thrown out with the bathwater because somebody came along with a newer, prettier bathtub that they wanted to sell. It is not a matter of— And because I've done both, I don't see one as superior to the other. And talking about the beauty of syntax, Jesus says what he appreciates the most about programming languages is their beauty, and whether they're old or they're new, it's wonderful when they're suited to the work involved. One of the beauties, I think that I can say that programming languages have some beauty, is that it's simple at the end, and the things that are simple—it's more difficult when you avoid complexity, more rich than the COBOL in terms of the features that you have to read. From that complexity also can open the door to security breaches. If the system is still are there after, in many cases, 20, 30, 40 years, it's because they're doing their work quite well. That summed it up very well. I mean, what technology can you think of that is in use right now that was—there are some, we know that with this series, we're seeing that some things we just can't get rid of. But to have this staying power to be as prevalent as it is, 20, 30, 40 years later—not many. And that says something about the makers of COBOL and the people who have adopted it. They saw a good thing and they held onto it. Not bad for a stopgap. Not bad. I think in situations like this one, there is a focus on newer being better when the older technology still does things well. Digital transformation is only as effective as the extent of human need and understanding. There's no reason why the old can't become new or at least maintain its relevance until the people behind the code are truly ready for intentional and meaningful change. Old can become new. Yep. Kim, what is the next episode in this series going to be? Excellent question. So we are Red Hatters and we are known for one really great product in particular. For the next episode, we are going to apply our number one original superlative and talk about the operating system. All right, well, that was it. I mean, we talked about COBOL as being an old language, but as we know, it's still out there. It's still running systems that we use each and every day. I would love to see a resurgence of COBOL. Would you? I would love to hear what you have to say about it, so hit us up @RedHat on Twitter using the #compilerpodcast, also on Instagram @RedHat. What are your thoughts about COBOL? Would you be willing to dip your toe into the programming world of COBOL just to help the world out a little bit? We'd be interested in hearing what your thoughts are. And that does it for this episode of Compiler. Today's episode was produced by Kim Huang and Caroline Creaghead. A big, big thank you to our guests, Scott Spurlock and Jesus Freire. If you think Victoria Lawton is anything short of amazing, tell me why, provide the specifics, support your argument logically. Our audio engineer is Robyn Edgar, special thanks to Shawn Cole, our theme song was composed by Mary Ancheta. Our audio team includes Leigh Day, Stephanie Wonderlick, Mike Esser, Nick Burns, Aaron Williamson, Karen King, Jared Oates, Rachel Ertel, Devin Pope, Matias Faundez, Mike Compton, Ocean Matthews, Paige Johnson, and Alex Traboulsi. If you liked today's show, help us out by following the show, rating the show, or leaving us a review. It really does help us out. Take care everybody. Until next time. All right, see you later.

More about professional development

Keeping up with changes in technology requires training and and engagement with learning opportunities—either in a traditional setting, or individually.

Articolo del blog

Friday Five — August 15, 2025 | Red Hat

15 agosto 2025  |  Red Hat Corporate Communications

...

Articolo del blog

Developing a standard AI OS: Unlocking production-grade AI at enterprise scale

14 agosto 2025  |  Brian Stevens

...

AI inference

About the show

Compiler

Do you want to stay on top of tech, but find you’re short on time? Compiler presents perspectives, topics, and insights from the industry—free from jargon and judgment. We want to discover where technology is headed beyond the headlines, and create a place for new IT professionals to learn, grow, and thrive. If you are enjoying the show, let us know, and use #CompilerPodcast to share our episodes.