Once you know a few programming languages, learning an extra is really easy. And COBOL is among the more easy.
It is good to start with a reasonably designed mainstream language like Python, Java, C#, Go,... and learn to think like a programmer. Then pick a few weirdos like lisp, prolog, haskell, and learn what languages can provide if stretched. COBOL, Basic, PHP,... are today less well designed language that will teach you bad habits. As a first language, you'll have to unlearn things to grow.
Cobol programmers tend to be less paid and work slowly with gnarly code bases. By definition, you work for businesses that are bureaucratic and slow in changing anything. Your colleagues will be near pension age. Do you want this company culture?
You will have work forca long time, of course.
Users already know you'll answer that lots of their questions are impossible. It's easy to say no to them when they e.g. request a strange UI change.
Being a (human) translator between cobol and the rest of the company is a nice path to architect. It's rare to find a programmer talking to both sides of the IT world.
Cobol itself isn't the biggest problem. Even the mainframe isn't. But everything else will be bespoke to the company, underdocumented, hard to learn. That may include the text editor you use.
I think python is an excellent "first" programming language, but I'd resist calling it "reasonably designed"; especially when holding it up as more reasonably designed than the likes of lisp or haskell.
As a programmer who was forced out of the education pipeline due to the courses being taught exclusively in C++, and forcing OOP to the point that my natural propensity toward immutable functional programming was consistently reprimanded as "programming wrong", that my first programming language became Bash as it was what I could use to automate my Linux box.
I later picked up Python, to do mathematics, that eventually led me back into the profession of programming.
> weirdos like lisp [...] haskell
Years later I discovered Clojure and Haskell which validated my original love of immutability and functional programming making those languages feel like the most "reasonably designed" and sensible languages. Like being wrapped in a warm blanket.
I agree with the others - do whatever you think is fun and inferesting at this age. Too many things will change before you get to the job market.
Having said that, reading up about Cobol can be fun and interesting, and unique.
I can also recommend this book about working with legacy systems. It makes for an interesting read:
(And also other classical books like Pragmatic Programmer etc)
But it's worth noting that what most of the places hiring COBOL developers actually need isn't someone that knows COBOL, but someone that knows how to develop for mainframe systems (using COBOL). If you just learn the COBOL language in a vacuum, you'll have a much harder time getting hired.
https://sebgroup.com/career/who-are-you/graduates-and-studen...
E.g. BEC has a programme described here: https://candidate.hr-manager.net/ApplicationInit.aspx?cid=10...
If you want to learn Mainframe and COBOL for fun I say do it. I did enjoy working with those technologies and you probably will too.
However if you want to do it because you think you'll make lots of money, unfortunately that is not the case. Yes I know you hear all the time about how COBOL programmers make bank. That is not quite true. They are not looking for people that know COBOL or Mainframe. They are looking for people that know their big ball of mud. If you know their big ball of mud they'll pay you a lot. However if you just know COBOL and they have to train you on their big ball of mud. Well they would rather send that work offshore to pay the lower wages. Any work done onshore is paid at low rates.
I haven't touched those systems since I left IBM 15 years ago. In fact I don't even have it on my resume anymore. Cloud technologies pay so much more and the jobs are easier to get.
I bring this up to you, as a 14 year old, to think about your future career. You have 8 years before you're out looking for work, then 45 years, give or take, in the industry. What is the likelihood that these COBOL systems will still be in place vs. finally being replaced? Yes, people have called the death of COBOL for years, and they were wrong, but one day they're going to be right.
That said, if you just have the interest in cobol, just go for any and just have fun. Don't worry at this point about how useful it will be.
That is to say, if you find COBOL and Fortran interesting go for it! But after 6 months or a year consider trying something else.
Learning boring technology and invisible infrastructure definitely can pay dividends. I don't think it's worth learning in isolation, but if you also engage in the relevant communities (think mailing lists, in-person conferences, company events, etc.) then the effort pays good dividends IME.
I'm a bit biased, but I recommend looking at APL[0]. For one, it has a legacy almost as old as COBOL, with large pieces of European infrastructure running on the language. At the same time, it's cutting edge in both performance and the software architecture principles it encourages. Heck, APL even runs on GPUs these days [1], boasting a solid route for learning modern GPU programming as well.
Also, the company behind the leading APL implementation these days, Dyalog[0], has some of the friendliest outreach around, and their yearly conferences are some of my favorites to attend.
Disclaimer: I am kind of in love with APL as a greenfield development language. Feel free to email me personally if you have any questions. Address is in my HN profile.
More to the point of OP's question, however, is the market share these languages command. I've read estimates that about half of banking software is still running on COBOL, somewhere in the ballpark of 100 billion SLOC or so. Fortran still sees active use in high performance libraries for scientific computing and supercomputer architectures, with solid C interop. Heck, a new Fortran spec even came out in 2023!
In other words, COBOL and Fortran both still command significant market niches. APL, similarly, has on the order of several billion SLOC running around in financial and healthcare institutions, not to mention a long tail of data science applications. This is mostly true in the Nordic countries.
APL the language is still alive and growing, getting yearly updates. Better yet, APL has a SotA compiler that can both host on and target GPUs. It's language model maps cleanly to hardware, which significantly eases reasoning about performance. At the same time it remains a high-level language where one can write production, performant, applications in just mere hundreds of SLOC, all while remaining pleasant to maintain and extend in my experience. Try saying that about any other language you know.
That is to say, any accusations that these languages are "obsolete" are a bit naïve, IMHO. There are solid careers to be had as developers in each of their industries, without having to grind your soul to a pulp trying to find employment in IT just to end up writing yet another CRUDy SPA.
In the past, it was possible to create truly innovative languages, but that is very rarely the case now. We are constantly bound by industrial standards, from syntax to functionality.
If you're into classic languages, learn Common Lisp, or Scheme, or APL. If you're into more recent stuff, try Caml, or Haskell, or perhaps Idris.
And don't worry too much about your employability: if you're smart and know two or three programming languages, you'll be able to adapt to whatever technology is fashionable when you start looking for a job.
This is a pretty gross oversimplification and it's also a mischaracterization to say it's "a more widely used and active version". I wouldn't even put it in the same catagory as traditional lisps since those will compile down to executables and clojure run in the JVM
They "kind of" do. `:executable t` does not actually make an executable in the way most people understand it. It's a big blob with lots of stuff you would expect to be stripped out in other languages. Short of paying several grand for Lispworks, you are not going to make true executables in something like SBCL.
In contrast, Clojure with GraalVM is fairly easy to do and will give you smaller binaries.
In Europe, fintech has a lot of legacy systems in COBOL, with no plans of getting rid of them anytime soon.
Also a lot of languages are starting to adopt features from the functional paradigm and it's always good to know where they came from. It's unfortunate that many engineers use techniques like memoization (via annotations for example) without understanding their underlying principles.
As for significant systems, Emacs is probably the most well known. Also the Clojure community is very active.
Op is posting about learning cobol for job prospects, so an esoteric fad language without job prospects is probably not the language they are after.
Also Lisp is far from an "esoteric fad language", it's been around since the 1960s, has both ISO and ANSI standard dialects, and has some significant usage in industry. Like COBOL most of the companies that use Lisp are using it in specialized situations (I would argue this is similar for most functional languages). I feel like it's not talked about as much as COBOL because for COBOL specifically there is a market demand to maintain legacy systems that outstrips the supply. Because of this the role of maintaining these systems - at least historically - paid very well.
Worst case scenario you become the youngest COBOL dev in the world and it becomes a really interesting talking point / part of your story.
https://web.archive.org/web/20160826003417/https://medium.co...
I remember getting taken thru the core interconnectivity of the mainframe at a bank and being shown a diagram of the key flows which didnt look to bad. They then overlayed all the flows and the screen was like a bowl of spagetti - and understanding that is where the real skill and expertise is
Thats probably true of most legacy systems
Learning COBOL will position yourself squarely in the legacy/maintenance role for large entities (banks, governments, etc.).
But, ask yourself, how long until those systems will eventually be completely revamped?
Fortran is a bit more versatile, but I've only ever seen it in the defense R&D industry - which is where I worked for some years.
But for the intellectual curiosity of it, sure, why not.
This question is at least 50 years old. The same applies for C, Fortran.
"Never touch a running system" is at giant corp a kind of Religion. Experiments through LLMs to attempt to convert existing COBOL programs in Java or modern languages have until now failed.
The reason people don't want to do it is because it's not fun at all. I once had a project where the client was a bank that needed some COBOL work done. They needed to make a few changes to a program that had been running for years. They gave me the program in printouts. Like I had 200 pages of COBOL to read. And the people working there were people who had been transfered here because they were not good. So they had no idea about what they were doing. The whole thing was extremely frustrating and we ended up dropping the project.
Only if you are a tiny handful of major financial centers or willing to drop everything and move to basically anywhere. If you are in a midsized city there is probably only 1 or 2 companies in need of COBOL developers and if they're not hiring you're screwed. I saw this happen to a friend of the family. He'd spent his entire 20 year career working as a mainframe and COBOL developer at the regional office of a Fortune 50 company in our home town. When he got let go, he literally could not find another job. There were plenty of programming jobs around, but not for someone who had spent their entire career programming COBOL.
But if what you're trying to do is invest in your future, I suggest learning RISC-V assembly and Verilog.
It was good fun and interesting, so if you have the time and interest I’d go for it.
If I had to guess, a 14yo would feel pretty bored very quickly.
> they will probably hire any young person who has learned a minimum of COBOL
This makes no sense
I've known a couple of people who worked as COBOL/mainframe developers in Europe at huge companies and their pay was definitely worse than what they could have gotten as a "a data engineer maintaining Spark" or anything else even similarly modern. The cage works both ways, on the one hand they might be hard to replace, but equally they'll have at least as hard a time finding a new job if they quit. Depending on where you live, the company you're working at might literally be the only company in that city using that particular tech stack.
What are you going to rebuild a banking mainframe system from the 1970s at home in your bedroom for fun?
I don't think it matters anyway. A 14yo thinking strategically like this will figure things out soon enough.
Being that young it would probably be best to not listen to what anyone else tells you though. Follow what you think is right and if it doesn't work out, learn from it. The whole idea could be explored and still not be old enough to drive.
The long rambling answer:
I've been joking that a high paying consultancy in COBOL is my eventual retirement plan for most of my life. Like most good jokes, its built on some kernels of truth.
One kernel of truth is that I've never shied away from touching and working on "legacy code" no matter what the language. In the corporate environments that have been the majority of my career I've been asked to touch all sorts of strange things. As many point out here and many will keep pointing out, the ability to learn or dive into programming language N+1 starts to get easier the more programming languages you already know, the more you can see the similarities and understand some of the major family trees. Showcasing those skills has been a valuable resource in several jobs, having the willingness to touch some of the legacy stinky apps has been a way to signal maturity and technical competence. It's helped boost my path to seniority in some of the companies I've worked at.
It has not been job security. Knowing the deep arcane knowledge of a company's "mission critical" legacy systems doesn't make you immune to layoffs. Companies know that you picked it up quickly, the next "sucker" may pick it up just as quickly.
Another kernel of truth in the joke is part of the "retirement job" part in that it is not the job I want next, it is the job I expect last. The more I've worked on legacy apps the less I want to work on legacy apps. I've always known that legacy apps are legacy for a reason. They aren't fun to work on. They aren't exciting things to put on your resume. If you have legacy languages and efforts on your resume that doesn't necessarily help you get the next job. Companies almost always have lofty ideas that "we'll eventually rewrite the legacy app in something modern and cool". Companies hire for "modern and cool" even when what they are actually looking for is "willing to touch old legacy cruft". Making the "COBOL is my retirement plan" joke in an interview has been the way to keep the legacy cruft out of my resume to leave more room for "modern and cool", but also signal "yes, I've done the legacy stuff, I expect to keep doing the legacy stuff".
An easily overlooked kernel of truth in the "retirement job" part is that I learned early on that you hear a lot about "there's very few people doing this job so they are highly paid" and found out that the "causal arrows" in these stories is a lot more confusing in real life. True legacy jobs like COBOL mainframe programmer aren't just high-paying because few people take or want to take those jobs, they are high-paying because few of those jobs exist. Those jobs aren't just packed by highly senior engineers where senior also means aged and near-retirement; those highest paying jobs are sometimes by their very nature the sinecures and endgames and "rewards" for high seniority developers in a company. In many cases you do literally retire into those jobs. They are "mission critical" enough to be worth paying high salaries to high senior engineers to keep working on them, but they are siloed enough and "slow enough" that they don't actually have a lot of work left to do other than just to have someone on call for the small bug fix or percussive maintenance. Companies know those can be sweet jobs to reward decades of loyalty, or luck of the draw. Companies know those can be jobs to dangle for someone to climb the ladder all the way up staying in individual contributor roles. So they are, in a lot of cases they are.
So to recap: it isn't really a path to job security, it isn't necessarily a path to get hired, and it isn't the path to high-paying jobs that it sounds like, because it isn't an "immediate path", especially not for someone fresh into the industry.
But all of that said, learn every programming language you can and have fun with it. The more languages you know the better a leg up you have to learning the next language. If you want to spend time today learning COBOL or Fortran, do it because it is fun, not because you expect it to pay off. Learning COBOL is surprisingly easy. It's a relative of BASIC in ways that aren't immediately obvious (in both directions of the family tree). Fortran isn't just legacy code, if you dig deep enough into Python data engineering you'll find that some of the underpinning code is new Fortran code in the 2020s. It's got the easy "foreign function interface"/cross-language binding of classic C, but is a language that's always been tuned for high performance math. ("FORmula TRANslation", it's name has always signaled it was a language designed first and foremost for math.) Learning Fortran in the context of a Python is a fun excuse to learn two or three languages in symbiosis.
Prolog is considered a "legacy" language but can be a lot of fun to explore and can be a bit mind-breaking because it uses logic programming in ways that few other programming languages do.
Common Lisp is considered a "legacy" language and has a lot of fun things to teach, like some of the earliest ideas of functional programming and cool ideas like code is data is code. Lots of languages have descended from Common Lisp on one branch or another, things you learn in Common Lisp have modern needs.
Smalltalk is considered a "legacy" language and is a fun way to explore early ideas in "Object-Oriented Programming" and "Actor-Oriented Programming" from their deepest, oldest source.
Javascript is both a "legacy" language and a living language and there's no end to what you can learn from it and its ecosystem.
There's all sorts of weird and fun languages in niches smaller or rarer than "legacy" languages, too. You can learn a lot from weird things like Inform 7 and Io and Lua and Elixir and whatever else you might stumble on here on Hacker News or embedded in your favorite game/game engine/game platform.
Learn everything that seems fun, and that will serve your career well. It will associate learning new languages as a fun activity that you enjoy doing, even if eventually it will be some job telling you you need to learn some old ugly thing for some "mission critical" app no one else really wants to touch. Hopefully some of the "fun" rubs off and you feel a little bit less miserable about the ugly dark cave in the hidden depths of some corporate structure they want you to do that in.
Thank you again for contributing to my growth in both computing and professionalism—I’m still far from reaching the end of my learning journey. In the end, I was right to make this post.