I’m just super interested to learn about this language that is effectively never used with the huge caveat that it still underpins some of the most critical financial and government systems.
Yes, somewhat for fun and somewhat for work. There are online cobol fiddle environments that can help you. Data is stored in something like a c Union on a buffer, and the programming style is pre-procedural, sort of like a very easy assembly language. The language is very wordy, and there aren't a lot of standard libraries.
It is ok for storing and updating records, but writing complex algorithms would be slow
Only very old editions of COBOL were pre-procedural. Not saying I would want to learn it "for fun". The only fun I had was trying to calculate in Input/Output storage (must be treated as write-only...) or maybe the many ways you could format your numbers. Modern Cobol could even be bearable (while wordy) but the environment in which it is normally used absolutely not: JCL lacks any unixy feel and everything on OS/390 is it's own special tool. Lucky if you even got DB2, not so lucky when having to do with VSAM...
I then got a short contracting gig when I needed some cash. It was good money - and I never wanted to do that kind of work again. The language has any number of deficiencies, that have been fixed by later languages. And as another commenter mentioned - the departments that use it have any number deficiencies, many of them political, that got them into this position.
I messed around with it, thinking it seemed interesting and could be useful to know Just-In-Case. One thing I didn't get, until I started messing with it, is that COBOL isn't a general purpose language. There's a whole category of things it just can't do, and if you ask about it you'll just be told "COBOL isn't C". There's another set of things it's really effective at, primarily transactions and large iterations.
Mess around with it if you want, sure. Just realize it's a limited language with specific use cases and you're unlikely to ever touch it outside of those, even as a hobby/"for fun".
Ya, transactional processing of what I would consider simple and well defined data it's what typically occurs with cobol at financial institutions. In this context the code has been around forever and all the 'Oops we lost your money' bugs have generally been purged from it'.
It lacks a whole slew of things you would expect in a GP language, or requires you to jump through massive hoops to achieve the same results.
Imagine trying to program a desktop application in SQL. You could probably achieve it through some use of triggers and interfaces, but it would be a nightmare. It's not quite as bad for COBOL, but a similar story.
IIRC it doesn't have a stack. So all variables are globals. There is no way to call a function with a parameter - to be accurate, there are only subroutines; no functions.
I did an internship in 2009-2010 with a company who used MicroFocus “AcuCOBOL” to modernize a green-screen automotive dealership management system into a Windows GUI.
I wouldn’t say I did it for fun, but I did do it for the learning experience. My university was very invested in COBOL, and I had classmates who got offers much larger than mine to work for various finance companies in Wisconsin, so I had already learned the basics of language.
It’s hard for me to separate the COBOL from all of the other dysfunctional things going on at the company. I knew that the language was a dead-end and did not want to get stuck with it. Not because I didn’t like the language, but because I was 21 and “Web 2.0” was in full swing and I knew I wanted to do something “cool”.
Migrating data files to new descriptors was always a stressful time. The equivalent of a database schema change, but you had to load the old files and rewrite in the new format largely manually.
The tooling we used felt dated, but worked well enough. Better than the tools we used in school.
I always used “Murach’s Structured COBOL” [1] as my primary reference. Carried that book just about everywhere during that time.
> It’s hard for me to separate the COBOL from all of the other dysfunctional things going on at the company. I knew that the language was a dead-end and did not want to get stuck with it. Not because I didn’t like the language, but because I was 21 and “Web 2.0” was in full swing and I knew I wanted to do something “cool”.
I think this is an often under-appreciated point -- languages don't live in isolation, but within a wider context of libraries, people using the language, and institutions and jobs with jobs that use the language.
As another example on this point -- at my current job, for some reason much of the backend has been written in Haskell. Haskell's a fine language, I actually really like many aspects of it. Our main product, however, is web based, a domain Haskell is completely able to handle on a technical level. In practice, though, it's a poor fit, and I find myself constantly puzzling at all the odd, non-idiomatic ways web architecture has been set up, often in ways that make it very difficult to make things work well for the web. In many cases, this has been carried over into some questionable typescript as the backend programmers then had to also try and become frontend programmers.
None of these problems are because of Haskell the language or because the original programmers were bad programmers, but because their background, and the majority of the Haskell ecosystem, just isn't really web-focused, and so conventions and assumptions most people who work mainly on the web take for granted they were unaware of or got wrong.
A language is more than just syntax and standard library, it's part of a broader culture.
To me, there’s an ecosystem and a culture for a language in a situation.
The ecosystem is the tooling around the language. Debugging, performance profiling, building and dependency management are examples.
The culture is how the language is used in real life. How stable is the ecosystem?
There are lots of beautiful languages that are used horrifically. Enterprise OOP is an example for me where more than half the code is dedicated to avoiding basic principles for “what if we want to change later” (looking at you getters and setters).
And within a company or software suite, there can be subcultures of how “we” use the language. Every class needs an interface. Our C is written OO (see old GNOME).
For the ecosystem you have extremes. C where debugging and performance profiling are well defined practice, but modern dependency management doesn’t exit. The JavaScript ecosystem changes so rapidly, documentation is usually out of date, “nobody does that anymore”, etc.
And so much awful comes from trying to force a language into something the language wasn’t originally designed or even used for. Your Haskell example here. Adding functional language features and convoluted asynch to every freaking language is another. People create things much harder to learn than a new language with a mature ecosystem and culture in a domain just to avoid “learning a new language.”
In woodworking, I can do pretty much anything with a chisel. But I plane with a plane, saw with a saw, use specialty planes for rabbets, etc. Each has a learning curve, but I’ll end up with a better, more consistent result. And really, they’re all just chisels with jigs in different configurations. But I’m going to use a chisel where it’s still best, like mortising. Well, and where I’m not sure I want to invest in a more specialized tool yet and risk my wife killing me. Then I use C… I mean, a chisel.
It felt weird at the time, but I think the reach of COBOL is underestimated by just about everyone. I just checked the university's website and they still have their introductory Programming in COBOL course as well as a 400-level "Applications in Information Systems" course that "includes coverage of advanced features of the COBOL language."
Northwestern Mutual is based in Milwaukee and is where most of the grads I knew who went down the COBOL path either started out or ended up.
I wouldn’t say I learned it “for fun”, but when my sister was in college (25 years ago) as a business information systems major (or something like that), she had to take a Cobol course so I learned enough of it to help her get through the class. Next semester, she told me she had to take a second Cobol class. I told her I was done with Cobol and she switched majors.
My girlfriend in High School and college was taking "Secretarial Science" like her mother but took Cobol for a laugh, maybe because I was taking every other language. Right out of college she got a job as the bum she married finally finished college on her nickel.
I had to deal with a bunch of mainframes in a previous job and tried to learn a bit of COBOL. One interesting thing I learned early on was that programs are almost never written exclusively in COBOL. The language isn't Turing complete (by design), so a significant portion of a program's logic will be captured in the JCL (Job Control Language) script that configures how the program will run and orchestrates multiple programs.
I'm not using the formal definition here -- I meant that there are programs you can write in other mainstream programming languages that just can't be expressed in COBOL due to limitations on recursion.
The COBOL spec doesn't allow recursive "paragraphs" (functions), though some implementations support it. (This may no longer be the case, or this limitation may have been specific to the language version used at my job.)
The main limitation is I/O, though. You typically use JCL to indicate what files/DBs a program will run against, and I recall that everything that touched the network was written in Java and called from JCL (whether this was because networking libraries don't exist in COBOl or because those that do are terrible, I couldn't say).
It was somewhat dependent on your job, although the norm is no recursion.
From Wikipedia "other compilers, like IBM COBOL, will produce code that prints "1 2 3 END END END END ..." and so on, printing "END" over and over in an endless loop." [1]
Also, having never used COBOL, the PERFORM statement is pretty cool. Like calling arbitrary parts of a Switch statement with a single line. Would be neat if some other languages had that.
While much-maligned, what JCL (and software like CLISTs and REXX for interactive processing) brings to the table in the mainframe world is a STANDARD way for programmers to not only decouple code and the data resources the code will process, but also a wealth of other functionality, including job accounting, priority, job classes, network routing of jobs & resources, conditional execution, run-time library management, resource caps, output management, catalog management & file disposition, real temporary files, file versioning (GDGs), storage & device management including tape, procedures, includes, symbolic variables, checkpoint restarts, etc.).
In non-mainframe realms, while the good news is that there's no JCL, the bad news is that individuals and companies have pretty much reinvented the JCL wheel over and over again, creating their own hodgepodge of unique, non-standard efforts to deliver smidgeons of similar functionality hacked together from a mix of shell scripting, environment variables, YAML, JSON, other config files, manual prompting, third-party libraries and software, and even hard-coding resources in programs.
I read 'Kill It with Fire: Manage Aging Computer Systems (and Future Proof Modern Ones)' and the whole time I kept thinking that learning one of these old languages could be fun and would be a good side project. Would definitely be a lot of good projects to work on if you looked for them as paid gigs.
I took a course in my undergrad for fun. It's an interesting design paradigm, all the code had a built in schema attached to it, if I recall correctly, which I've come to appreciate and find more interesting over time.
Using the AS400 was very interesting as well.
The problem about COBOL, for me, is it's so specifically designed to fill a niche of business record processing, that I'd never use it for a side project. It's too verbose, and too restricting.
I learned COBOL in college just to learn it, and I loved the verbosity of it. Verbosity was kind of the point: if you name your variables properly, you have self-documenting code.
Yes, the processing COBOL does is restricting, but then my first full-time programming job was two and a half years writing RPG II code. COBOL would have been an upgrade.
I'd add that with legacy codebase the hardest thing is to untangle the business logic buried in. Some of it is likely still the core of the business but not many people, if at all, clearly know it and the docs are often dated and no longer in sync with the code.
I've actually seen some of the COBOL that underpins these financial entities. Typically the code base and writing style has morphed into a number of nearly incompatible dialects over the decades it has ran at these places. I've never really learned enough about it to understand copybooks and the other functions/file types it has.
Decade? My team once happened to maintain a file that was originally checked-in in the 1970s... (edit: Not sure if I'm more in awe of the fact that the procedure was still used or because mainframe code was under version control in the 70s and you still can see who did what and why).
I had a COBOL class in school and I enjoyed. At the time I didn't think about it, but today it feels more like a DSL than a general purpose programming language.
There are lots of things that I would rather do for fun than program in COBOL.
I have programmed in COBOL on ICL and IBM computers. You don't just program in COBOL, you need to learn SQL, JCL, TSO, CICS, etc. Maybe it is simpler with MicroFocus (or similar) COBOL on Linux, haven't ventured there.
I was working with a bunch of COBOL programmers and learned the language as an act of solidarity. Wrote a basic API framework in it.
I really love it. I think there are a number of language features (like the memory handling) which have elements missing from a lot of modern languages.
It's on my list of languages to learn, but I haven't gotten to it yet.
My first job was supporting a custom application running in UniVerse on Solaris. It originally ran on a Prime mainframe and UniVerse was one of the ways you could run this type of software on a modern system. I really enjoyed working in the Pick MultiValue environment. In many ways, this was a NoSQL database from before NoSQL was a big thing.
I don't work in this world anymore, but I've been playing with ScarletDME (a fork of OpenQM, another MultiValue database, from before they closed the source) and seriously enjoying it.
As a result of this first job I've got a special place for "old" programming languages/environments. My dream retirement job is to work for either the CRA or IRS supporting their old systems. Between the complexities of income tax and the old-school code that can never be retired I think I'd love it.
NoSQL databases (in the sense of key/value stores) are a very old idea. I never understood why that was such a hotness. The pendulum never stops I guess.
i wouldn't say fun, but it is easy. back in the 1980s i had to write a couple of cobol programs to unpack some dec10 isam files so that i could import them into our spiffing new ibm 4381 4gl (nomad/2 if anyone is interested). i read a cobol tutorial in the morning, and wrote the programs in the afternoon. only problem was my spelling - i couldn't spell "environment" as in cobol's ENVIRONMENT DIVISION.
and as others have observed, it's the infrastructure (JCL, TP monitors, etc.) which is the real problem.
Yeah, I learned COBOL for sort-of-fun (in the sense that it wasn't strictly for a paid gig) a long time ago. It went pretty well, in that I learned that, while it isn't a fun language in any sense of the word, it Just Works and even adheres to the revered Unix principle "do one thing, and do it well" in most production situations.
Most COBOL programs have a very well-defined batch-oriented flow: take this file, process it, then output these file(s) within N hours. Reliability is paramount: batches often run overnight, and you don't want operators getting angry with you. And there is an entire ecosystem, all consisting of proprietary (and expensive) IBM solutions like CICS, that make CRUD apps (which, admit it, is like 80% of all software...) pretty much a piece of cake.
The downside of all this, is that you're very much limited to whatever your vendor allows, that progress is glacial, and that innovation is pretty much unheard of (since that might break the batch, which is... a mortal sin). And, like with the Unix philosophy, orchestration of all those single-minded processes becomes an issue after a (short) while.
If anyone were to ask me whether they should "learn the language", my answer would be an unqualified no, unless it's for a specific paid assignment. There are no unique ideas hiding anywhere in COBOL that are absent from more modern (and more 'fun') languages.
But does it matter to learn the language paradigms and orchestration requirements? Sure: you may land a good gig if you understand where AS400s/i-Systems/whatever fit in, and it may give some insight into where things like Docker and K8S are coming from.
81 comments
[ 3.4 ms ] story [ 227 ms ] threadIt is ok for storing and updating records, but writing complex algorithms would be slow
I then got a short contracting gig when I needed some cash. It was good money - and I never wanted to do that kind of work again. The language has any number of deficiencies, that have been fixed by later languages. And as another commenter mentioned - the departments that use it have any number deficiencies, many of them political, that got them into this position.
It is not something I would recommend for fun.
Mess around with it if you want, sure. Just realize it's a limited language with specific use cases and you're unlikely to ever touch it outside of those, even as a hobby/"for fun".
Anecdotally I was talking with a COBOL vendor way back in the mid-80s and he had mentioned that their COBOL compiler was itself written in COBOL.
FORTRAN also suffered limitations back in the day, notably lack of dynamic memory, yet folks were able to write sophisticated systems in it as well.
Imagine trying to program a desktop application in SQL. You could probably achieve it through some use of triggers and interfaces, but it would be a nightmare. It's not quite as bad for COBOL, but a similar story.
I wouldn’t say I did it for fun, but I did do it for the learning experience. My university was very invested in COBOL, and I had classmates who got offers much larger than mine to work for various finance companies in Wisconsin, so I had already learned the basics of language.
It’s hard for me to separate the COBOL from all of the other dysfunctional things going on at the company. I knew that the language was a dead-end and did not want to get stuck with it. Not because I didn’t like the language, but because I was 21 and “Web 2.0” was in full swing and I knew I wanted to do something “cool”.
Migrating data files to new descriptors was always a stressful time. The equivalent of a database schema change, but you had to load the old files and rewrite in the new format largely manually.
The tooling we used felt dated, but worked well enough. Better than the tools we used in school.
I always used “Murach’s Structured COBOL” [1] as my primary reference. Carried that book just about everywhere during that time.
[1]: Murach's Structured COBOL https://a.co/d/hONfFT7
I think this is an often under-appreciated point -- languages don't live in isolation, but within a wider context of libraries, people using the language, and institutions and jobs with jobs that use the language.
As another example on this point -- at my current job, for some reason much of the backend has been written in Haskell. Haskell's a fine language, I actually really like many aspects of it. Our main product, however, is web based, a domain Haskell is completely able to handle on a technical level. In practice, though, it's a poor fit, and I find myself constantly puzzling at all the odd, non-idiomatic ways web architecture has been set up, often in ways that make it very difficult to make things work well for the web. In many cases, this has been carried over into some questionable typescript as the backend programmers then had to also try and become frontend programmers.
None of these problems are because of Haskell the language or because the original programmers were bad programmers, but because their background, and the majority of the Haskell ecosystem, just isn't really web-focused, and so conventions and assumptions most people who work mainly on the web take for granted they were unaware of or got wrong.
A language is more than just syntax and standard library, it's part of a broader culture.
To me, there’s an ecosystem and a culture for a language in a situation.
The ecosystem is the tooling around the language. Debugging, performance profiling, building and dependency management are examples.
The culture is how the language is used in real life. How stable is the ecosystem?
There are lots of beautiful languages that are used horrifically. Enterprise OOP is an example for me where more than half the code is dedicated to avoiding basic principles for “what if we want to change later” (looking at you getters and setters).
And within a company or software suite, there can be subcultures of how “we” use the language. Every class needs an interface. Our C is written OO (see old GNOME).
For the ecosystem you have extremes. C where debugging and performance profiling are well defined practice, but modern dependency management doesn’t exit. The JavaScript ecosystem changes so rapidly, documentation is usually out of date, “nobody does that anymore”, etc.
And so much awful comes from trying to force a language into something the language wasn’t originally designed or even used for. Your Haskell example here. Adding functional language features and convoluted asynch to every freaking language is another. People create things much harder to learn than a new language with a mature ecosystem and culture in a domain just to avoid “learning a new language.”
In woodworking, I can do pretty much anything with a chisel. But I plane with a plane, saw with a saw, use specialty planes for rabbets, etc. Each has a learning curve, but I’ll end up with a better, more consistent result. And really, they’re all just chisels with jigs in different configurations. But I’m going to use a chisel where it’s still best, like mortising. Well, and where I’m not sure I want to invest in a more specialized tool yet and risk my wife killing me. Then I use C… I mean, a chisel.
At eleven years, that sounds more like an apprenticeship than an internship.
Northwestern Mutual is based in Milwaukee and is where most of the grads I knew who went down the COBOL path either started out or ended up.
The COBOL spec doesn't allow recursive "paragraphs" (functions), though some implementations support it. (This may no longer be the case, or this limitation may have been specific to the language version used at my job.)
The main limitation is I/O, though. You typically use JCL to indicate what files/DBs a program will run against, and I recall that everything that touched the network was written in Java and called from JCL (whether this was because networking libraries don't exist in COBOl or because those that do are terrible, I couldn't say).
Recursion and loops are interchangeable.
From Wikipedia "other compilers, like IBM COBOL, will produce code that prints "1 2 3 END END END END ..." and so on, printing "END" over and over in an endless loop." [1]
Also, having never used COBOL, the PERFORM statement is pretty cool. Like calling arbitrary parts of a Switch statement with a single line. Would be neat if some other languages had that.
[1] https://en.wikipedia.org/wiki/COBOL#Procedures
In non-mainframe realms, while the good news is that there's no JCL, the bad news is that individuals and companies have pretty much reinvented the JCL wheel over and over again, creating their own hodgepodge of unique, non-standard efforts to deliver smidgeons of similar functionality hacked together from a mix of shell scripting, environment variables, YAML, JSON, other config files, manual prompting, third-party libraries and software, and even hard-coding resources in programs.
Grass is always greener, as they say. :-)
https://www-40.ibm.com/servers/resourcelink/svc00100.nsf/pag...
Using the AS400 was very interesting as well.
The problem about COBOL, for me, is it's so specifically designed to fill a niche of business record processing, that I'd never use it for a side project. It's too verbose, and too restricting.
Yes, the processing COBOL does is restricting, but then my first full-time programming job was two and a half years writing RPG II code. COBOL would have been an upgrade.
In one word - minefield!
http://www.coboloncogs.org/INDEX.HTM
Haven't used it in anger though.
I have programmed in COBOL on ICL and IBM computers. You don't just program in COBOL, you need to learn SQL, JCL, TSO, CICS, etc. Maybe it is simpler with MicroFocus (or similar) COBOL on Linux, haven't ventured there.
Learn COBOL in a day
https://news.ycombinator.com/item?id=37388560
COBOL gets new life in the cloud thanks to Watsonx and AI
https://news.ycombinator.com/item?id=37277191
I really love it. I think there are a number of language features (like the memory handling) which have elements missing from a lot of modern languages.
My first job was supporting a custom application running in UniVerse on Solaris. It originally ran on a Prime mainframe and UniVerse was one of the ways you could run this type of software on a modern system. I really enjoyed working in the Pick MultiValue environment. In many ways, this was a NoSQL database from before NoSQL was a big thing.
I don't work in this world anymore, but I've been playing with ScarletDME (a fork of OpenQM, another MultiValue database, from before they closed the source) and seriously enjoying it.
As a result of this first job I've got a special place for "old" programming languages/environments. My dream retirement job is to work for either the CRA or IRS supporting their old systems. Between the complexities of income tax and the old-school code that can never be retired I think I'd love it.
and as others have observed, it's the infrastructure (JCL, TP monitors, etc.) which is the real problem.
https://github.com/victorqribeiro/perceptronCobol
Most COBOL programs have a very well-defined batch-oriented flow: take this file, process it, then output these file(s) within N hours. Reliability is paramount: batches often run overnight, and you don't want operators getting angry with you. And there is an entire ecosystem, all consisting of proprietary (and expensive) IBM solutions like CICS, that make CRUD apps (which, admit it, is like 80% of all software...) pretty much a piece of cake.
The downside of all this, is that you're very much limited to whatever your vendor allows, that progress is glacial, and that innovation is pretty much unheard of (since that might break the batch, which is... a mortal sin). And, like with the Unix philosophy, orchestration of all those single-minded processes becomes an issue after a (short) while.
If anyone were to ask me whether they should "learn the language", my answer would be an unqualified no, unless it's for a specific paid assignment. There are no unique ideas hiding anywhere in COBOL that are absent from more modern (and more 'fun') languages.
But does it matter to learn the language paradigms and orchestration requirements? Sure: you may land a good gig if you understand where AS400s/i-Systems/whatever fit in, and it may give some insight into where things like Docker and K8S are coming from.