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.
hosuew 49 days ago [-]
> reasonably designed mainstream language like Python
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.
Genius_um 49 days ago [-]
Thank you for your response. Actually, I don't really intend to pursue a professional career in COBOL; it was more of an excuse to learn a new, rather old language that interested me, just like many other programming languages I’d like to explore. However, it was still interesting to know what would await me if one day, on a whim, I developed a deep passion for this particular language. COBOL is still a part of computing history, and it’s only fair to draw knowledge from it.
hyperman1 49 days ago [-]
What could anybody have against learning something new. Follow your hearth and go build something! I've heard of someone implementing tetris in labview, which is completely against its purpose and was loved by everyone who saw it.
kolinko 49 days ago [-]
Cobol by itself is quite simple, it’s the whole code and architecture that is convoluted.
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)
Genius_um 49 days ago [-]
Thanks for the advice and resource.
dagw 49 days ago [-]
The largest bank in Sweden offers a free 16 week COBOL training course and basically a guarantees job if you pass. That's how desperate they are to hire new COBOL developers.
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.
ochrist 49 days ago [-]
Something similar is happening in Denmark as well, as several large fintech companies rely on mainframe technology and COBOL.
I worked at IBM for 7 years and I worked with mainframe and AS/400 systems while I was there.
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.
Genius_um 49 days ago [-]
Thank you for your response. After reading all these replies, I clearly understood that COBOL is not as accessible as it might seem from a (very) distant professional perspective. I was just curious to learn more. However, these posts mention quite a lot that it is still a good language to learn.
ralphc 49 days ago [-]
Last night I saw an interview with the US Treasury Secretary and one of of the "DOGE bros", Sam Corcos. He is tasked with modernizing the IRS's computer systems. Some of the highlights included him saying that this modernization has already taken place at most banks, and that they're hopeful to do this in the government with roadblocks gone.
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.
user32489318 49 days ago [-]
From the economics perspective you might be right. But, keep in mind that you will be working with 60-70 yo, who have been working and maintaining the same code base for the past 30 years. With age, neuro elasticity decreases, comprehending new concepts becomes though. Unwillingness to learn is the killer of any improvement.
A grumpy old man might be a funny meme, but, waging a war with your colleagues on every change in the code is a solid drain on your mental health.
You’re young, any mistake you might make is a learning opportunity. Learn COBOL if you want, it’s always a plus, but stay in touch with anything else. Work takes a solid part of your life, having good connection with your colleagues, doing stuff you’re challenged by, .. all this is equally important to the job security
user32489318 49 days ago [-]
not to put cobol engineers in a bad light, but, the most bright engineers I have had chance to work with always seek ‘more’, they grow. Consider who would be willing to stay and work on the same project, doing the same for extended periods of time. I’m not calling it lazy or unintelligent, but, these may be work-challenge averse and an opportunity to offload a lot of work on your shoulders. If this mentality matches with your way of working, you will be fine.
noobermin 49 days ago [-]
Since you're young, learn what you want based on what interests you. My best advice right now is not to focus on languages but on projects. Think about a particular project you're interested in creating and try to make it. The language required for said project will become apparent after a little googling.
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.
aabhay 49 days ago [-]
Generally, no, as a principle. You don’t want to learn things in chronological order, you want to learn them in intrinsic ness order, to the extent it is feasible. If you really want to learn computing, start from scratch. Go from logic gates to building logic boards to cpu architecture, assembly, and then programming. That will allow you to pick up arbitrary skills in a compounding way.
blackbear_ 49 days ago [-]
I think that 14 years old is too young to specialize. Your free time, which for now is plenty but will become less and less, would be better spent exploring and learning ad many things as possible according to your personal interests rather than following the job market. The next 5/10 years will be times of great change for you and you never know what will come your way, so the more things you know and explore the more opportunities you will have. You will have plenty of time to specialize once you know you are on the right path.
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.
xelxebar 49 days ago [-]
What a perceptive question!
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.
Thank you for your response. I was curious to know whether COBOL (and all the other languages from that era) still had real professional value worth seriously exploring. I’ve often been interested in older languages for learning purposes, but I actually rushed through APL too quickly. I had looked at some source code and initially thought it was an exotic programming language because of the many special characters I saw. But I was wrong—this language is quite well-designed and powerful. I'll take a closer look at it; it also seems interesting.
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.
noobermin 49 days ago [-]
APL is a far cry from cobol, the only commonality is both are old and considered obsolete by some.
xelxebar 49 days ago [-]
OP mentions "old languages" like COBOL and Fortran, which first appeared around 1959 and 1957, respectively. APL showed up around 1966, so it's in the same ballpark era-wise.
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.
spratzt 49 days ago [-]
As somebody who has written both COBOL and APL, I can assure you that they are both obsolete.
jech 49 days ago [-]
Don't. Learn something fun instead.
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.
eimrine 49 days ago [-]
If you are so smart that you are able to do this, why don't you want to learn Lisp? Cobol is mostly USA-only AFAIK and there aren't much reasons to keep Cobol except not wanting to buy new hardware.
unfixed 49 days ago [-]
Disagree with Cobol being USA-centric language.
In Europe, fintech has a lot of legacy systems in COBOL, with no plans of getting rid of them anytime soon.
kruxigt 49 days ago [-]
[dead]
hsbauauvhabzb 49 days ago [-]
Are there any significant systems and/or job prospects for lisp?
c0n5pir4cy 49 days ago [-]
I don't think there are many companies that use it as a primary language (maybe a few in clojure) - but I'm confident that learning a lisp dialect or other functional language makes you a more rounded programmer. Once you have a grasp of functional concepts you can easily port these to other languages and there is some demand in those languages (Scala, F#).
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.
hsbauauvhabzb 49 days ago [-]
So the answer is no then.
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.
c0n5pir4cy 49 days ago [-]
I mean if looking directly at the market for job prospects yes, if becoming a good engineer and being able to excel in those roles it's a different thing - at 14 exploring various technologies is not only beneficial but also enjoyable.
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.
hsbauauvhabzb 48 days ago [-]
Maybe the original post should have been prefaced with ‘I know you’re specifically asking about job prospects, but here’s a language without job prospects that I think is cool’. I’m not saying that learning lisp would be a mistake, and not saying op could do with some guidance relating to which languages to learn, but I don’t think the original post is a good way of discussing either and imo is misleading in what it presents. I also don’t think a 14 year old learning to code should start with lisp.
Genius_um 49 days ago [-]
I've been interested in Lisp before, but Clojure seems to be a more widely used and active version. I'd have to learn it again; the syntax is quite interesting.
drpossum 49 days ago [-]
> Clojure seems to be a more widely used and active version
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
Capricorn2481 39 days ago [-]
> 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.
financetechbro 49 days ago [-]
I think it could be interesting. There are only a few Thousand COBOL developers left, median age is in their 60s-70s or something like that. Don’t know the extent of the problem but I know VC/growth investors are thinking about it. Had a chat with one this week, not on this topic, but they brought up COBOL and basically hinted that ATM infra would collapse if a COBOL dev decides to take too long of a vacation (hyperbole).
Worst case scenario you become the youngest COBOL dev in the world and it becomes a really interesting talking point / part of your story.
I wouldn't bank on a job in COBOL. I took several COBOL courses at an IBM affiliated university and enjoyed the language. I wanted to work in COBOL. I sent out dozens of applications and heard nothing back. I'm not saying "don't learn COBOL." That said, COBOL isn't a particularly difficult language, but at your age, I'd learn something more modern, and if in 5-6 years you are still interested in COBOL, learn it then.
fiftyacorn 49 days ago [-]
Its not the learning of COBOL thats the issue - its the custom nature of a lot of older systems and understanding the associated business logic.
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
TrackerFF 49 days ago [-]
There are plenty of niche languages one can learn, that will land you niche jobs.
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.
madduci 49 days ago [-]
> But, ask yourself, how long until those systems will eventually be completely revamped?
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.
d--b 49 days ago [-]
COBOL will guarantee your employment, but beware that anything written COBOL is going to be deeply corporate stuff. It will mean that it is hosted by a company that doesn't need nor want to change, or worse that it's reluctant to put any money into upgrading its infrastructure.
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.
dagw 49 days ago [-]
COBOL will guarantee your employment
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.
snvzz 48 days ago [-]
Absolutely no harm in learning COBOL. The language itself is simple, and you'll quickly figure out why it isn't the one of choice anymore.
But if what you're trying to do is invest in your future, I suggest learning RISC-V assembly and Verilog.
ecornflak 49 days ago [-]
I’m old enough to have learned COBOL at university, although that was the mid 90’s and says more an about the university than my age.
It was good fun and interesting, so if you have the time and interest I’d go for it.
pacomerh 49 days ago [-]
In the late 80's I was taking a general computer course and one of my classes was COBOL. The teacher told me it wasn't gonna be practically useful anymore, however he said it was good for historical context. I don't regret it.
cedws 49 days ago [-]
Learn what you want, you have more time and freedom now than you ever will.
gtirloni 49 days ago [-]
COBOL is ok. The issue is the type of companies we will work for and the processes around old mainframe systems (which what you'd ended working on)
If I had to guess, a 14yo would feel pretty bored very quickly.
howard941 49 days ago [-]
Good question for a HN poll
nprateem 49 days ago [-]
No. Learn something decent.
> they will probably hire any young person who has learned a minimum of COBOL
This makes no sense
user32489318 49 days ago [-]
His argument makes sense. This of someone who is exclusively working with cobol and a specific version of a very specific mainframe. If he is staying there for 5-10 years, where would he go? Are these skills transferable? Would he become a data engineer maintaining Spark, no one would hire someone with a senior salary with no experience with a bit more modern stack.
In reverse, company is unlikely to let him go, sourcing a replacement would be a nightmare. This is a gold cage opportunity
dagw 49 days ago [-]
This is a gold cage opportunity
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.
spratzt 49 days ago [-]
Even as an entry level business analyst you’re probably make more than a COBOL programmer. Don’t touch it.
borgdefenser 49 days ago [-]
It is also a problem that the projects are not realistic.
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.
masijo 49 days ago [-]
Stop thinking about the job market bro, you're 14. Go outside and have fun.
WorldMaker 49 days ago [-]
The short answer: if you want to learn languages like COBOL or Fortran, do it, but do it for FUN, not for some idea of eventual profit or job security.
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.
Genius_um 49 days ago [-]
Thank you for getting involved in this great advice. I knew I wasn’t actually going to pursue a professional career in COBOL; in fact, it was just a way to justify my learning of this language and even other languages from the same era. I'm trying to immerse myself in the mindset of programmers from that time, in addition to everything modern today. I have a certain fascination for old things that have been abandoned—it’s often a legacy that shouldn’t be ignored, especially if it took a long time to develop or if it has matured significantly. It would be quite narrow-minded not to take an interest in what was done in the past to satisfy one's thirst for learning. But COBOL itself would really be my last option if I had to look for a job, though it’s still worth paying attention to its market demand. Fortunately, there are many other jobs in programming.
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.
throawayonthe 49 days ago [-]
[dead]
coolThingsFirst 49 days ago [-]
[flagged]
Rendered at 07:05:15 GMT+0000 (UTC) with Wasmer Edge.
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:
https://a.co/d/4r4Svx8
(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.
E.g. BEC has a programme described here: https://candidate.hr-manager.net/ApplicationInit.aspx?cid=10...
https://sebgroup.com/career/who-are-you/graduates-and-studen...
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.
[0]:https://dyalog.com/
[1]:https://github.com/Co-dfns/Co-dfns
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.
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.
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.
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.
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.
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.