Readit NewsGenius_um commented on · Posted by u/Jgrubb
It seems to work well now
Genius_um commented on When You're on Vacation, Be on Vacation dontbreakprod.com/posts/w... · Posted by u/dorkrawk
Indeed, starting to commit or do someone a favor "quickly" can quickly ruin a day or even a weekend. It can even lead to additional work for the next few working days.
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.
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.
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.
I won't say yes or no, but here is my experience:
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.
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.
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.
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.
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)
Thanks for the advice and resource.