12 ms·

Ask HN: Has anyone here learned COBOL for fun?

66 points by pcloadletter_ 3y ago

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.

skbadshah 3y ago
[flagged]
mooreds 3y ago
Honestly, I downloaded https://sourceforge.net/projects/gnucobol/ https://sourceforge.net/projects/gnucobol/ and read a tutorial but didn't go further.
CraigRo 3y ago
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
- mkesper 3y ago
  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...
vinni2 3y ago
I had to learn it as part of my undergrad. It was the most unfun course of my undergrad.
- nmcfarl 3y ago
  This was exactly my experience. 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.
deaddodo 3y ago
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".
- pixl97 3y ago
  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'.
- whartung 3y ago
  Curious what the limitations were. 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.
  - deaddodo 3y ago
    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.
  - sreeramvenkat 3y ago
    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.
marpstar 3y ago
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. [1]: Murach's Structured COBOL https://a.co/d/hONfFT7 https://a.co/d/hONfFT7
- anyonecancode 3y ago
  > 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.
smackeyacky 3y ago
Assembler is more rewarding as an intellectual exercise. Unless you really want to do rote record processing, in which case knock yourself out.
- queuebert 3y ago
  I agree, but getting to know some of the environments and JCLs in the Cobol world is useful breadth of knowledge to fight the Microsoft monoculture.
mayoff 3y ago
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.
- flaptrap 3y ago
  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.
giaour 3y ago
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.
- tyingq 3y ago
  I'm with you on the idea that mainframe COBOL is typically only part of the actual program. But COBOL not being Turing complete sounds...not right.
  - tgv 3y ago
    I'm fairly sure it is. You can literally write to tape.
  - giaour 3y ago
    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).
    - paulddraper 3y ago
      Recursion is not necessary for Turning completeness. Recursion and loops are interchangeable.
    - araes 3y ago
      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. [1] https://en.wikipedia.org/wiki/COBOL#Procedures https://en.wikipedia.org/wiki/COBOL#Procedures
topherjaynes 3y ago
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.
- pcloadletter_ 3y ago
  I think the author was a part of US Digital Service, which works to modernize government systems. Seems like fascinating and frustrating work.
deleted 3y ago
[deleted]
joaquincabezas 3y ago
reading frequently on HN how COBOL is still running critical tasks, I would rather say "for fun and profit"
aeonik 3y ago
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.
- degrees57 3y ago
  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.
taway32r41 3y ago
Like with most languages, learning the language is easy. Learning all the libraries, especially the undocumented proprietary ones, is the hard part.
- zoomablemind 3y ago
  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. In one word - minefield!
pixl97 3y ago
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.
- kimi 3y ago
  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).
  - pixl97 3y ago
    Decades with an 's', yea, this code has been around a very long time in most cases.
criddell 3y ago
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.
scns 3y ago
Well, for web programming there is this: http://www.coboloncogs.org/INDEX.HTM http://www.coboloncogs.org/INDEX.HTM Haven't used it in anger though.
GianFabien 3y ago
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.
ChrisArchitect 3y ago
Some COBOL stories caught my eye recently around here: Learn COBOL in a day https://news.ycombinator.com/item?id=37388560 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 https://news.ycombinator.com/item?id=37277191
b800h 3y ago
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.
Mister_Snuggles 3y ago
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.
- SoftTalker 3y ago
  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.
moffkalast 3y ago
"Has anyone here been stabbing themselves in the eye for fun? How did it go?"
zabzonk 3y ago
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.
atum47 3y ago
It was fun. Not even that hard, to be honest. https://github.com/victorqribeiro/perceptronCobol https://github.com/victorqribeiro/perceptronCobol
PreInternet01 3y ago
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.
- deleted 3y ago
  [deleted]
codegeek 3y ago
I learned COBOL in college circa 2001 for one of the CS courses and it was so much fun. The task was to do a project together with another person in our class and then present it to the rest of the class. I remember loving the simplicity and how much "Plain English" the language was. Good toy project.
asow92 3y ago
My wife made a COBOL mortgage calculator back in college for her CS programming languages course. She said it was more verbose than she would have liked, but it worked nonetheless. We keep joking maybe she should apply for one of those high paid legacy COBOL jobs that make their way into the news cycle now and then.
nwsm 3y ago
I took a mainframe class in college (2016) after my mom encouraged me to (she just recently retired as a COBOL/JCL developer of 35+ years). We learned COBOL and JCL on zOS and completed IBM's Master the Mainframe challenge. It was a very interesting experience and a different paradigm than any other CS/information systems classes I took. I could have gotten a job doing this work very easily. When I was applying and interviewing at my university career fair, I got a lot of interest and a couple job offers from having this class on my resume, but the pay wasn't good (small city it the south US that I wanted to leave), and I didn't want to lock myself into mainframes.
- phoehne 3y ago
  I don't know if it's still true, but when we were doing a analysis of alternatives for a customer looking to modernize, we reviewed salary surveys to determine the future cost of maintenance. While COBOL developers were about 15% cheaper than Java developers, our concern is that (long term) it would dis-incentivize developers from learning COBOL.
- kjs3 3y ago
  small city it the south US that I wanted to leave Columbus, GA, by any chance?
bluesmoon 3y ago
I can't say that I specifically learnt COBOL for fun because I did it in 1997 or so in India when the entire Indian IT industry was bidding on a host Y2K migration projects. I only graduated college in May 2000, so I never actually used COBOL to solve any Y2K problems, however, I did figure out that you could use a large number of paragraphs in the SCREEN SECTION to build animation frames and use that to build fun animations. It was tedious though, so I wrote a C++ program to generate the SCREENs for the COBOL program.
xwdv 3y ago
A curiosity, nothing more. And those high paying COBOL jobs pay a lot because the applicants have 20+ years of COBOL experience, not just because they happen to know COBOL.
ochrist 3y ago
I've coded in a lot of different programming languages over the past forty years or so, some of them for fun, some of them as part of my job. I've also coded COBOL at a few places, both on PC and on mainframes years back. But I can honestly say that I have never done anything in COBOL for the fun of it. However this is not to dissuade anybody from ever doing this. COBOL and a few other old languages are still used in areas like banking today. So you might cross it at some point in time, even at the most modern workplace. But as others have written in the comments, there is more to it than the language itself. You should really have a mainframe emulator (like Hercules) and other parts of the environment like CICS, TSO, ISPF and JCL if you really want to know how it feels like to code in COBOL. I don't know if it's even possible to get all of this up and running for free, but that could be a challenge in itself.
phoehne 3y ago
I don't know about fun, but maybe you can cosplay a1970's/1980's developer. The press (and many managers, directors, and even developers) treat COBOL knowledge as something that was doled out between 1965 and 1985 and then the world just ran out of it. Policy and decisions are made around COBOL as if it's impossible to understand and all knowledge has been lost. That leads to some pretty crazy situations. It's a language that's built for one purpose, business style applications like CRMs or accounting systems. It's not mystically bad or so undecipherable. It's actually a pretty simple language. If you're consulting/contracting developer, or an in-house developer at a bank, insurance company, etc., you should learn it. Even if you don't do anything with it, you can pick up a used book on COBOL and get most of the regular patterns and practices. Learning the basics of the language itself, if you've already a competent programmer, won't take you long. Maybe a half dozen weekends. But COBOL exists in an environment (normally IBM mainframes) that does a lot of the other lifting. CICS is an application server for COBOL (essentially). JCL manages what job to run and when. VSAM for indexed files or DB2 are the most common databases. And WebSphere for messaging. Becoming a 'real' COBOL developer on a mainframe is maybe 33% COBOL and the rest a miasma of mainframe-isms. And unlike Linux, there's no 'free' equivalent to a mainframe. (Although you can spend about $40 a day accessing a mainframe on IBM's cloud). A few weekends won't turn you into a COBOL migration expert, but you can at least join the rest of us, rolling our collective eyes, when the governor of New Jersey asks for volunteer cobalt [sic] programmers because some key system is breaking down.
srhtftw 3y ago
Back in the 80's a friend and I took a COBOL course at a community college in the evening when we were in high school. Most students were much older than we were. We wrote our programs on special pads of paper, transferred them to punch cards, gave our decks to operators who would run our programs on an IBM. Around a half hour later the operators gave us back printouts with the results of our runs. Most people didn't wait around but my friend and I would stay late so we could get more runs in. If we were nice to the operator they might bump our job up in the queue. Most of the programs we wrote were very simple. Things you could easily do now with a few lines of a modern scripting language. Our class's teacher was a professional COBOL programmer who had a day job working at a soda company. Some kind of emergency came up at his job half way through the course and he stopped showing up so we were left on our own for a few weeks. Just before the end of the class the department head took over and told everyone they would need to implement a binary search on the final exam. This was way too hard for most of the other students but not a big deal for my friend and I. We were done in a few minutes. I was also fortunate to meet another guy in the class who asked me to help him with some programs he had to write at his job. He was a soil engineer who wanted to move into a finance job but found the programming work difficult, so I spent a few hours a week tutoring him and writing programs with him. Eventually I graduated and he ran out of work for me but by then we became good friends. While I can't say I got much out of of the COBOL class I'm glad I took it because if I hadn't I would not have met him.
- tomcam 3y ago
  I think I speak for many readers of Hacker News when I say that I never imagined COBOL to be fertile ground to develop lasting human relationships
- nar001 3y ago
  I Hope your friend got to move into the finance sector? Did he get a grasp of programming after a while?
  - srhtftw 3y ago
    He never got the hang of programming but he did eventually transition into a nice job in finance at a small startup called Sun Microsystems.
rupurt 3y ago
We're doing Mainframe modernizations/integrations with the cloud @Mechanical Orchard. It's been really fun to see and learn the entomology of how computing got to where it is today. As other folks have described programming on the mainframe is about learning COBOL + JCL. I would also add that you need to understand how to read/write binary files according to a defined schema (Copybook) and encoding (EBCDIC, COMP, COMP-3, COMP-5). It's also helpful to deeply understand the intricacies of Db2 and different methods of connection (ODBC, JDBC, Db2 CLI). I've even gone so far as to write an ODBC extension for DuckDB so that we can scan and process queries faster and with less MIPS usage. https://github.com/rupurt/odbc-scanner-duckdb-extension https://github.com/rupurt/odbc-scanner-duckdb-extension https://www.mechanical-orchard.com https://www.mechanical-orchard.com
- BenjiWiebe 3y ago
  Not sure what word you were looking for, but entomology is the study of bugs. Etymology, maybe? The study of the history of words? "People who don't know the difference between etymology and entomology bug me in ways I cannot put into words."
  - xwowsersx 3y ago
    Seems like a typo and they meant "evolution"
  - rupurt 3y ago
    Thank you :) Etymology is what I meant. Been using the wrong word my whole life... :0
cardiffspaceman 3y ago
As a teenager in 1975, I was interested in programming, and found that my county library branch had introductory books on a half-dozen languages, including COBOL. I checked out each book and implemented a small set of programs. I had no machine, I carefully desk-checked each program. In the case of COBOL, calculations were tedious. I escaped into the loving arms of the COMPUTE statement. I later read that this was a cultural violation similar to using unPythonic code in Python. But I didn’t have a mentor, much less a reviewer. I think this counts as “for fun”. I later earned minor ducats writing little RPG programs, and the rest of my career has been far, far away from such programs.
jerhewet 3y ago
I was paid to throw COBOL in the late 1970's, and I would bag fries before I'd do it again. RPG2 was fun, TUTLY was ... interesting. COBOL? Never again.
anonzzzies 3y ago
The biggest thing is that it’s not the language. Cobol is trivial for any seasoned programmer, however no one is looking for a ‘just’ cobol programmer, they are looking for someone who understands and knows the ins and out of the mainframe (etc) eco system. I don’t mind cobol as a language; it’s very friendly to read imho and writing is too much typing but not hard.
mcraenich 3y ago
I took a class on it around 2013 in college, mainly out of interest, not because I wanted to use it. It was that experience that convinced me I'd never actually want to work with it for money. It was an interesting experience, but absolutely nothing about it was enjoyable, the language, the tooling, the support. All of it.
runjake 3y ago
Back in the 1980s, when it was still the business language. I don't have enough nostalgia in me to even glance at it now, unless a big paycheck accompanies it.
gilcot 3y ago
Here. Lean it just for fun and curiosity, and never use it in my career.
nobozo 3y ago
One thing I believe was true in the COBOL+JCL world of the 1980s is that you couldn't write a program that would read the name of a file, and then open that file. All files to be accessed had to be specified statically with JCL. Am I remembering correctly?
deleted 3y ago
[deleted]

66 points by pcloadletter_ 3y ago

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.

skbadshah 3y ago

[flagged]

mooreds 3y ago

Honestly, I downloaded https://sourceforge.net/projects/gnucobol/ https://sourceforge.net/projects/gnucobol/ and read a tutorial but didn't go further.

CraigRo 3y ago

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

mkesper 3y ago
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...

vinni2 3y ago

I had to learn it as part of my undergrad. It was the most unfun course of my undergrad.

nmcfarl 3y ago
This was exactly my experience. 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.

deaddodo 3y ago

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".

pixl97 3y ago
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'.
whartung 3y ago
Curious what the limitations were. 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.
- deaddodo 3y ago
  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.
- sreeramvenkat 3y ago
  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.

marpstar 3y ago

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. [1]: Murach's Structured COBOL https://a.co/d/hONfFT7 https://a.co/d/hONfFT7

anyonecancode 3y ago
> 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.

smackeyacky 3y ago

Assembler is more rewarding as an intellectual exercise. Unless you really want to do rote record processing, in which case knock yourself out.

queuebert 3y ago
I agree, but getting to know some of the environments and JCLs in the Cobol world is useful breadth of knowledge to fight the Microsoft monoculture.

mayoff 3y ago

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.

flaptrap 3y ago
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.

giaour 3y ago

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.

tyingq 3y ago
I'm with you on the idea that mainframe COBOL is typically only part of the actual program. But COBOL not being Turing complete sounds...not right.
- tgv 3y ago
  I'm fairly sure it is. You can literally write to tape.
- giaour 3y ago
  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).
  - paulddraper 3y ago
    Recursion is not necessary for Turning completeness. Recursion and loops are interchangeable.
  - araes 3y ago
    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. [1] https://en.wikipedia.org/wiki/COBOL#Procedures https://en.wikipedia.org/wiki/COBOL#Procedures

topherjaynes 3y ago

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.

pcloadletter_ 3y ago
I think the author was a part of US Digital Service, which works to modernize government systems. Seems like fascinating and frustrating work.

deleted 3y ago

[deleted]

joaquincabezas 3y ago

reading frequently on HN how COBOL is still running critical tasks, I would rather say "for fun and profit"

aeonik 3y ago

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.

degrees57 3y ago
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.

taway32r41 3y ago

Like with most languages, learning the language is easy. Learning all the libraries, especially the undocumented proprietary ones, is the hard part.

zoomablemind 3y ago
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. In one word - minefield!

pixl97 3y ago

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.

kimi 3y ago
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).
- pixl97 3y ago
  Decades with an 's', yea, this code has been around a very long time in most cases.

criddell 3y ago

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.

scns 3y ago

Well, for web programming there is this: http://www.coboloncogs.org/INDEX.HTM http://www.coboloncogs.org/INDEX.HTM Haven't used it in anger though.

GianFabien 3y ago

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.

ChrisArchitect 3y ago

Some COBOL stories caught my eye recently around here: Learn COBOL in a day https://news.ycombinator.com/item?id=37388560 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 https://news.ycombinator.com/item?id=37277191

b800h 3y ago

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.

Mister_Snuggles 3y ago

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.

SoftTalker 3y ago
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.

moffkalast 3y ago

"Has anyone here been stabbing themselves in the eye for fun? How did it go?"

zabzonk 3y ago

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.

atum47 3y ago

It was fun. Not even that hard, to be honest. https://github.com/victorqribeiro/perceptronCobol https://github.com/victorqribeiro/perceptronCobol

PreInternet01 3y ago

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.

deleted 3y ago
[deleted]

codegeek 3y ago

I learned COBOL in college circa 2001 for one of the CS courses and it was so much fun. The task was to do a project together with another person in our class and then present it to the rest of the class. I remember loving the simplicity and how much "Plain English" the language was. Good toy project.

asow92 3y ago

My wife made a COBOL mortgage calculator back in college for her CS programming languages course. She said it was more verbose than she would have liked, but it worked nonetheless. We keep joking maybe she should apply for one of those high paid legacy COBOL jobs that make their way into the news cycle now and then.

nwsm 3y ago

I took a mainframe class in college (2016) after my mom encouraged me to (she just recently retired as a COBOL/JCL developer of 35+ years). We learned COBOL and JCL on zOS and completed IBM's Master the Mainframe challenge. It was a very interesting experience and a different paradigm than any other CS/information systems classes I took. I could have gotten a job doing this work very easily. When I was applying and interviewing at my university career fair, I got a lot of interest and a couple job offers from having this class on my resume, but the pay wasn't good (small city it the south US that I wanted to leave), and I didn't want to lock myself into mainframes.

phoehne 3y ago
I don't know if it's still true, but when we were doing a analysis of alternatives for a customer looking to modernize, we reviewed salary surveys to determine the future cost of maintenance. While COBOL developers were about 15% cheaper than Java developers, our concern is that (long term) it would dis-incentivize developers from learning COBOL.
kjs3 3y ago
small city it the south US that I wanted to leave Columbus, GA, by any chance?

bluesmoon 3y ago

I can't say that I specifically learnt COBOL for fun because I did it in 1997 or so in India when the entire Indian IT industry was bidding on a host Y2K migration projects. I only graduated college in May 2000, so I never actually used COBOL to solve any Y2K problems, however, I did figure out that you could use a large number of paragraphs in the SCREEN SECTION to build animation frames and use that to build fun animations. It was tedious though, so I wrote a C++ program to generate the SCREENs for the COBOL program.

xwdv 3y ago

A curiosity, nothing more. And those high paying COBOL jobs pay a lot because the applicants have 20+ years of COBOL experience, not just because they happen to know COBOL.

ochrist 3y ago

I've coded in a lot of different programming languages over the past forty years or so, some of them for fun, some of them as part of my job. I've also coded COBOL at a few places, both on PC and on mainframes years back. But I can honestly say that I have never done anything in COBOL for the fun of it. However this is not to dissuade anybody from ever doing this. COBOL and a few other old languages are still used in areas like banking today. So you might cross it at some point in time, even at the most modern workplace. But as others have written in the comments, there is more to it than the language itself. You should really have a mainframe emulator (like Hercules) and other parts of the environment like CICS, TSO, ISPF and JCL if you really want to know how it feels like to code in COBOL. I don't know if it's even possible to get all of this up and running for free, but that could be a challenge in itself.

phoehne 3y ago

I don't know about fun, but maybe you can cosplay a1970's/1980's developer. The press (and many managers, directors, and even developers) treat COBOL knowledge as something that was doled out between 1965 and 1985 and then the world just ran out of it. Policy and decisions are made around COBOL as if it's impossible to understand and all knowledge has been lost. That leads to some pretty crazy situations. It's a language that's built for one purpose, business style applications like CRMs or accounting systems. It's not mystically bad or so undecipherable. It's actually a pretty simple language. If you're consulting/contracting developer, or an in-house developer at a bank, insurance company, etc., you should learn it. Even if you don't do anything with it, you can pick up a used book on COBOL and get most of the regular patterns and practices. Learning the basics of the language itself, if you've already a competent programmer, won't take you long. Maybe a half dozen weekends. But COBOL exists in an environment (normally IBM mainframes) that does a lot of the other lifting. CICS is an application server for COBOL (essentially). JCL manages what job to run and when. VSAM for indexed files or DB2 are the most common databases. And WebSphere for messaging. Becoming a 'real' COBOL developer on a mainframe is maybe 33% COBOL and the rest a miasma of mainframe-isms. And unlike Linux, there's no 'free' equivalent to a mainframe. (Although you can spend about $40 a day accessing a mainframe on IBM's cloud). A few weekends won't turn you into a COBOL migration expert, but you can at least join the rest of us, rolling our collective eyes, when the governor of New Jersey asks for volunteer cobalt [sic] programmers because some key system is breaking down.

srhtftw 3y ago

Back in the 80's a friend and I took a COBOL course at a community college in the evening when we were in high school. Most students were much older than we were. We wrote our programs on special pads of paper, transferred them to punch cards, gave our decks to operators who would run our programs on an IBM. Around a half hour later the operators gave us back printouts with the results of our runs. Most people didn't wait around but my friend and I would stay late so we could get more runs in. If we were nice to the operator they might bump our job up in the queue. Most of the programs we wrote were very simple. Things you could easily do now with a few lines of a modern scripting language. Our class's teacher was a professional COBOL programmer who had a day job working at a soda company. Some kind of emergency came up at his job half way through the course and he stopped showing up so we were left on our own for a few weeks. Just before the end of the class the department head took over and told everyone they would need to implement a binary search on the final exam. This was way too hard for most of the other students but not a big deal for my friend and I. We were done in a few minutes. I was also fortunate to meet another guy in the class who asked me to help him with some programs he had to write at his job. He was a soil engineer who wanted to move into a finance job but found the programming work difficult, so I spent a few hours a week tutoring him and writing programs with him. Eventually I graduated and he ran out of work for me but by then we became good friends. While I can't say I got much out of of the COBOL class I'm glad I took it because if I hadn't I would not have met him.

tomcam 3y ago
I think I speak for many readers of Hacker News when I say that I never imagined COBOL to be fertile ground to develop lasting human relationships
nar001 3y ago
I Hope your friend got to move into the finance sector? Did he get a grasp of programming after a while?
- srhtftw 3y ago
  He never got the hang of programming but he did eventually transition into a nice job in finance at a small startup called Sun Microsystems.

rupurt 3y ago

We're doing Mainframe modernizations/integrations with the cloud @Mechanical Orchard. It's been really fun to see and learn the entomology of how computing got to where it is today. As other folks have described programming on the mainframe is about learning COBOL + JCL. I would also add that you need to understand how to read/write binary files according to a defined schema (Copybook) and encoding (EBCDIC, COMP, COMP-3, COMP-5). It's also helpful to deeply understand the intricacies of Db2 and different methods of connection (ODBC, JDBC, Db2 CLI). I've even gone so far as to write an ODBC extension for DuckDB so that we can scan and process queries faster and with less MIPS usage. https://github.com/rupurt/odbc-scanner-duckdb-extension https://github.com/rupurt/odbc-scanner-duckdb-extension https://www.mechanical-orchard.com https://www.mechanical-orchard.com

BenjiWiebe 3y ago
Not sure what word you were looking for, but entomology is the study of bugs. Etymology, maybe? The study of the history of words? "People who don't know the difference between etymology and entomology bug me in ways I cannot put into words."
- xwowsersx 3y ago
  Seems like a typo and they meant "evolution"
- rupurt 3y ago
  Thank you :) Etymology is what I meant. Been using the wrong word my whole life... :0

cardiffspaceman 3y ago

As a teenager in 1975, I was interested in programming, and found that my county library branch had introductory books on a half-dozen languages, including COBOL. I checked out each book and implemented a small set of programs. I had no machine, I carefully desk-checked each program. In the case of COBOL, calculations were tedious. I escaped into the loving arms of the COMPUTE statement. I later read that this was a cultural violation similar to using unPythonic code in Python. But I didn’t have a mentor, much less a reviewer. I think this counts as “for fun”. I later earned minor ducats writing little RPG programs, and the rest of my career has been far, far away from such programs.

jerhewet 3y ago

I was paid to throw COBOL in the late 1970's, and I would bag fries before I'd do it again. RPG2 was fun, TUTLY was ... interesting. COBOL? Never again.

anonzzzies 3y ago

The biggest thing is that it’s not the language. Cobol is trivial for any seasoned programmer, however no one is looking for a ‘just’ cobol programmer, they are looking for someone who understands and knows the ins and out of the mainframe (etc) eco system. I don’t mind cobol as a language; it’s very friendly to read imho and writing is too much typing but not hard.

mcraenich 3y ago

I took a class on it around 2013 in college, mainly out of interest, not because I wanted to use it. It was that experience that convinced me I'd never actually want to work with it for money. It was an interesting experience, but absolutely nothing about it was enjoyable, the language, the tooling, the support. All of it.

runjake 3y ago

Back in the 1980s, when it was still the business language. I don't have enough nostalgia in me to even glance at it now, unless a big paycheck accompanies it.

gilcot 3y ago

Here. Lean it just for fun and curiosity, and never use it in my career.

nobozo 3y ago

One thing I believe was true in the COBOL+JCL world of the 1980s is that you couldn't write a program that would read the name of a file, and then open that file. All files to be accessed had to be specified statically with JCL. Am I remembering correctly?

deleted 3y ago

[deleted]