I've spent the last three years translating COBOL programs off of an HP3000 in to to SQL-backended web-apps and can say as a non-Programmer who was given a pile of COBOL source to decompile, I like its simplicity and ease of readability. Most of the code is from the 80's or 90's but is well commented and easy to work with and understand. Speaking of, most of this code still works or was in use until 2-3 years ago--on the HP3000. Its a testament to how long this stuff can be kept useful. Also, the COBOL team here wasn't astoundingly well paid, but good stable and low-stress jobs in the middle-range of local income is something that is becoming harder and harder to find.
There is such a thing as unnecessary comments and I only add comments myself when factors outside of the immediately visible code are effecting the logical flow... but removing other people's comments (other then auto-doc style ones) is a really bad habit.
You're essentially invalidating the opinion of whoever thought it was important to put a comment there in the first place and, unless it's done after a team discussion on the types of comments to include in code, it's being done unilaterally.
The difference to sex is that comments are unnecessary if the project is in good shape otherwise. Yes, no code is really self-documenting, but requirements documents, handbooks, documentation comments, VCS logs and tests should make it possible to elucidate weird code parts.
Bad comments are detrimental: some are outdated comments that were forgotten to remove or to update, and others were wrong or misleading to begin with. Some are just redundant (they might state the obvious) and might become misleading later on. Their existence is of historical interest in the best case.
When comments are bad they can be actively misleading and when comments are everywhere they can do nothing but obscure logic. I like well commented code, but poorly commented code can be worse than uncommented code that's clearly written. Lastly, adding comments to code doesn't always add value.
Until some COBOL developer publishes his pay slip, I will stick to reality, top IT salaries are at tech giants.
From personal experience: BNP Paribas is one of the biggest bank in the world, top 5 if you exclude Chinese state owned ones, and they pay mainframe related jobs like shit.
Being young, smart and with a whole career ahead, you have no future working has a COBOL developer, no one should spend his life picking up shitty code left by his elders decades ago.
> no one should spend his life picking up shitty code left by his elders decades ago.
Would you say that to a civil engineer who works on infrastructure maintenance?
Computing is critical infrastructure in many areas of government and business. The solution to all problems cannot be “screw it, we’ll just rewrite in Go with a React frontend.” Some things should be rewritten and some should be maintained.
Have you ever worked on an IT infrastructure where there is no comments in the source code, no documentation, no normalization, no specs? I am not talking about COBOL itself, I am talking about those COBOL jobs, it's only about fixing and/or maintaining. I hope no one is writing new things in COBOL.
Back in the day... COBOL programmers were often 'analysts' as well - meeting with the end users and/or management to design and then implement the required system.
Funny to me how so many in this thread rag on COBOL, yet when other languages come up it is always 'well this language is good for abc but I wouldn't really do xyz in that one'. COBOL is extremely good at what it was designed for - data processing, and lots of it.
> COBOL is extremely good at what it was designed for - data processing, and lots of it.
Well, the hardware that COBOL usually runs on is good for that, sure. And its usually (now) running legacy systems that no one wants the risk of reimplementing from the ground up. But is the language itself particularly well-suited to the task? I think that’s less clear. Certainly, I’ve never seen a coherent argument about how the language itself is superior to modern alternatives even for large scale data processing; if it was, it would be popular for greenfield projects in that domain, you’d think.
One thing I have heard about COBOL is that it has a built in, decimal fixed point type. Very few of the modern languages have an native type like this. Having a decimal fixed point type makes monetary calculations easier to do more reliably.
> One thing I have heard about COBOL is that it has a built in, decimal fixed point type. Very few of the modern languages have an native type like this..
What modern language doesn’t have either fixed-point or arbitrary-precision decimals (or both) in either the core language or standard library?
I mean, sure, C doesn’t (and I don’t think C++ does), but those aren’t particularly modern languages.
In don’t think that Java fits the bill either in this regard. White it does have BigDecimal in the standard library, it is both slower(because object and supports arbitrary precision) and more cumbersome (no operator overloading ) than a native type.
I can see a case for decimal floating point types, but fixed point adds nothing beyond what can be performed directly via arithmetic on the underlying integers. It's basically a convenience feature.
It's suited for a very specific kind of data processing. It's a kind which isn't typically used today.
The language combines presentation and storage in a way I've never seen in any other language. Let's say you have an 8 digit variable. You can then specify that the last two digits is represented by a different variable, and thus the second variable will only work on those last two digits.
This is useful when you have formatted fields, where you have a variable that holds an ISO 8601 date, with other variables representing the year, month and day parts.
In a language like Java, you need to create a class that holds this information, with separate methods to manipulate the individual components and formatting the output.
In COBOL you only need a few lines of declarations to do this.
The drawback is that now presentation is tightly associated with the data storage, meaning that changing presentation format can be a lot of work. This is why COBOL programs were so problematic during Y2K.
That is true, but you have to understand that not everybody is FAANG material. The top 5-15 tech companies receive hundreds of thousands of resumes every year of which less than 1% are selected. Also not everybody is interested in moving in to the tech hubs. There is still lot of work in legacy code - COBOL, Oracle and other legacy systems.
Even in newer languages like Java, there is lot of work that is mostly application maintenance and adding new features to existing decade old applications. It is not bad work.
Yes and that's always the discussion when people from US come in to visit to the french part of companies. "Hey we heard that you are paid 5 to 10 times less than us, why do you accept that?"
Trust me, it's worth it. Really, it's not that much effort and it's worth it to signal to recruiters your real worth. And don't forget not all recruiters are equal.
And the visa issue is way overblown. It's easier than you think for a real engineer with experience.
At least for me, I criticize from experience: I worked with COBOL, and think it's an awful, unfun language, commonly used for unfun projects. And COBOL jobs don't pay particularly well where I live, either.
> In my country and in Sweden it is quite easy to get good and stable job in banking/insurance/consulting business
Yes, that much is true: a stable job in banking/insurance. Mostly maintaining clunky legacy systems. If that's what you aspire to, and aren't passionate about software -- which is perfectly fine! -- I guess learning some COBOL is a reasonable career choice.
> If that's what you aspire to, and aren't passionate about software -- which is perfectly fine! -- I guess learning some COBOL is a reasonable career choice.
This is a completely unfair assessment. Even if you're passionate about something, job stability and good pay are going to be the primary drivers in decisions about jobs. I doubt that most people choose, say, Java jobs because they're passionate about Java, or even software in general, for example.
From what I gather, most people leave the "passion" part of their work to part-time hobby work, allowing them to do both. If it then translates into money, good, but the few successes that have been put on blast have blinded people to the reality that passion != money.
Believe me: writing Java is on average more interesting than COBOL (I've done both, including some terrible Java systems using Enterprise Java Beans -- I still shudder at the thought -- and Java still wins). Then again, Java has been called "the next COBOL", so that's an interesting comparison.
> Even if you're passionate about something, job stability and good pay are going to be the primary drivers in decisions about jobs.
For a lot of people, yes. Not for all. And even then, it's hard to argue that COBOL is cool or interesting. It's just paying the bills, but nothing to get hyped or write gushing articles about. And there are more interesting programming jobs that will also pay the bills, anyway.
If there aren't, there aren't. In that case, there's no choice to be made.
I didn't mean to judge people and in fact tried not to, though perhaps clumsily. I said it's fair to not be passionate about the job. Often I haven't felt passionate about it either, or even particularly motivated. And do note I have worked in COBOL, so I understand the need. I just don't like the language and I don't want to see people selling the idea that it's "interesting" or a particularly sound business decision to learn it -- like those articles that occasionally get posted to HN.
I'd argue maintaining clunky legacy systems requires more passion for software. It's easy enough to run off to a startup and make the same CRUD app that's been made 1000x before, but maintaining something that grew organically over decades, that takes craftsmanship.
> I'd argue maintaining clunky legacy systems requires more passion for software.
This is one of those things that is easy to discuss in theory, but in practice it doesn't work that way, at least not in most cases. And in my experience working with COBOL at a bank: no, the employees weren't passionate about it. In fact, the only passionate employee was an old guru who wrote assembly code for the bank's mainframe.
You could take it to an extreme, and argue that working with malfunctioning computers, using only BASICA.COM for DOS, writing accounting software and getting paid mere cents for it, requires more passion -- after all, who would want to work like this if they didn't feel passionate about it -- but of course it isn't.
It's great to work in challenging or atypical projects, maybe with tools that are not the easiest or more ergonomical, but there's a baseline of comfort below which you're probably not passionate, just masochistic.
Agreed about the general BS meaning of "passion", but in this case I meant "liking software and building things with it". People maintaining legacy corporate systems written in COBOL -- the most common usage of this language -- don't exactly belong in this category. Which, as I said before, is perfectly fine: not everyone has to like software, maybe a job is just a job and you just need the paycheck. But all those recurrent articles praising COBOL somehow manage to forget this...
If most of programming is code maintenance, and you think of that as an anti-passion activity, your “passion for programming”—you didn’t state that explicitly, but let’s be real about the implicit comparison you’re drawing here—may be a mirage.
I’ve always heard COBOL devs referred to as either highly paid consultants keeping critical applications alive for corporations or wage slaves maintaining a painful app for below average pay.
I've heard it's the computer science equivalent of a plumber or janitor. The job doesn't sound particularly fun, but because of this it's high demand and great pay. It's a good job if you accept that work isn't fun, and you don't care about climbing the ladder, you're just looking for a decent, reliable income.
An alarming amount of software development, especially now, is little more than plugging part A into part B. The major trend of software development has been to increase the degree of similarity between software developers and plumbers.
That kind of reductionist argument can be made for any kind of software development...we're all just plumbing bits around at the end of the day. If you're a web dev, you're plugging web tech, if you're a backend dev it's network protocols and storage tech, if you're a kernel dev it's instruction sets and memory buffers.
As we build tools to make that plumbing easier for certain use cases, we might move around in the hierarchy to plug different things together, but I don't think anything has fundamentally changed in an alarming way. We're still just moving bits around!
Of course, you're absolutely right in your reductive view, but it is not what I was trying to suggest.
I remember an explanation that Sussman gave for why MIT retired the SICP course, replacing with it a course in which students program robots with Python.
He said (and I'm badly paraphrasing) that one used to be able to scale up your reasoning about how a piece of software works in a similar way to how you do it when looking at a circuit diagram: you have these little components with discrete behaviors and you can simply combine them and be able to predict the result.
Today, however, as programmers (to a greater extent than before) we create systems by cobbling together large, opaque, libraries whose properties are poorly described and require one to essentially "do science" on those black boxes.
And the trade-off is that we're often better off plugging A into B, and hence there's a lot more of that sort of line work in industry.
edit: I should say that I don't much like that sort of work, but it was unwarranted to say it is 'alarming' that the trend has gone this way.
So if you're a plumber and you're looking at two parts that don't connect but need to, you're pretty much SOL; you can't fabricate an adapter on the spot. Now, if you're a software engineer and you find yourself in a similar situation, you're expected to "fabricate the adapter." This is why the plumber analogy is fundamentally flawed.
It's not a particularly well-paying or common job. I live an area with a large number of insurance companies and banking HQs, so COBOL jobs are a little more common than most of the US. Most job postings are for contractors paying mid-30s to lower 40s per hour, with a handful in the 50s.
That's an okay salary in absolute terms, but it's not a great one for a software engineering position. Even in a fly-over state.
But taking that job is basically career suicide. After 3-5 years of doing that, you'll be completely unemployable outside of insurance unless you spend time on your own learning useful skills. And if you do that, you're probably starting back down in a junior or mid-level role.
Anyone would be much better off getting an AWS cert and learning to write SQL.
Do these jobs train you in on COBOL, or do you have to be an expert in it already? If you have to be an expert already how are people learning COBOL / preparing for the interview to get this kind of job?
Having applied to a few COBOL jobs in my youth, and getting no response back, I suspect that the COBOL shortage is like the general "programmer shortage" in that it really means "(senior) programmer shortage (willing to work for below prevailing wage)"
If you're experienced in another language, you can learn COBOL in a week or two. My first job out of school was with a consulting firm that would take new-hire non-programmers and have them on a client site writing COBOL in 3-4 weeks.
A list of many of these "bad things" can be found in BabyCobol [1, 2] -- it's a "toy model" of COBOL, specifically because COBOL has a lot of strange features that modern tooling doesn't/can't handle well.
I make a bit under $20k per month base (a bit under $30k with equity) for a Silicon Valley firm, doing Python and Java and Go and the like, and I suspect I have a lot more career portability. That said, it's extraordinarily impressive for Europe, even the expensive parts of Sweden!
Recently I had a look at some COBOL out of curiosity, and as someone used to modern languages it appeared very verbose and awkward - far less complex conceptually, but the syntax itself is not at all lightweight.
It seemed to be more or less as expected - fairly straightforward and apparently easy to learn, but unattractively bureaucratic.
My understanding is that you don't get paid the top money for knowing the language but for being able to understand and maintain/revise the kinds of systems it operates - which is a whole other level of skill and experience, and not something you can just pick up in a few evenings of side projects.
That kinda depends, as a Dane I honestly only ever need to think in EUR when I shop online from Germany. I do however need to convert from DKK to USD and back much more frequently when reading news online.
Technically most of Europe don't need convert to EUR, they already use Euros so they're also more likely to need to convert to USD.
Since the OP offers a relative comparison in saying COBOL jobs pay three times more than a Java jobs, the currency or any currency conversion to $USD really doesn't matter.
I was forced to take a COBAL & z/OS course during college.
And I was pretty good at it.
Local bank wanted to make sure it had a steady supply of COBAL programmers.
I hate COBAL a lot, and incidentally for many of the same reasons I hate Java.
My first job, after graduating, was for Control Data Corporation. I was called a Systems Analyst, but what I did was write a lot of Cobol code. Many years later, I wrote a paper about a novel data structure that could be used for what is called "The Balance Line Algorithm". I illustrated the use of this data structure with some Cobol. That was the last time I even thought about Cobol until I came across a citation to my paper. In excitement at being cited, I looked at the reference in the citing paper. Imagine my disappointment when I read the citation: "[X]showed that this can even be done in Cobol".
I do not get all the hatred. The idea behind COBOL’s syntax is the same as SQL’s: it is merely yet another “Structured English Query/Programming Language” designed, initially, for non-programmers to be able to describe in words what it is they would like to accomplish in a way they could be understood by the computer.
The hatred comes from people like me, who have worked with COBOL and will tell you it's terribly frustrating to work with, needlessly verbose in multiple places where it doesn't need to be, and often used in banks for purposes which are the death of all you hold dear or interesting to work with.
COBOL is not an interesting programming language these days, and you should not learn it unless you need it for your current job.
> [COBOL was] designed, initially, for non-programmers to be able to describe in words what it is they would like to accomplish in a way they could be understood by the computer.
Let me tell you a secret. It doesn't work for non-programmers. The complexity of "Z = X + Y" is no more or less than "ADD X TO Y GIVING Z", and bugs will happen at the same rate with either syntax. The added verbosity will only annoy you.
Another myth surrounding COBOL is that as its programmers age, there is a lack of them and therefore COBOL jobs are high-paying and you should learn it to make good money. The reality: I've never met a really wealthy COBOL programmer -- or rather, one who was wealthy because he/she knew COBOL. That's not where the money is. COBOL jobs are not particularly well-paying, and there are young people learning it, and no, they don't get awesome paychecks.
It wasn't designed to work, it was designed to please senior management.
Grace Hopper: “I used to be a mathematics professor. At that time I found there were a certain number of students who could not learn mathematics. I then was charged with the job of making it easy for businessmen to use our computers. I found it was not a question of whether they could learn mathematics or not, but whether they would. […] They said, ‘Throw those symbols out — I do not know what they mean, I have not time to learn symbols.’ I suggest a reply to those who would like data processing people to use mathematical symbols that they make the first attempt to teach those symbols to vice-presidents or a colonel or admiral. I assure you that I tried it.”
> Throw those symbols out — I do not know what they mean, I have not time to learn symbols.
Wouldn't it be easier to just use C/C++, and define macros like "PLUS" that explands to "+", "MINUS" that expands to "-", "BECOMES" that expands to "=", etc.?
> COBOL jobs are not particularly well-paying, and there are young people learning it, and no, they don't get awesome paychecks.
Yup. All the articles on the shortage of COBOL programmers is actually companies whining that they can't find cheap labor. If they paid well, they'd have their pick of young and old.
> All the articles on the shortage of COBOL programmers is actually companies whining that they can’t find cheap labor.
The word “COBOL” isn’t necessary in that sentence.
And, for that matter, “programmers” could be replaced with any skilled work field for which such complaints exist.
An actual shortage of labor (where the demand curve is above the supply curve at all price points) is theoretically possible, but in the real world nearly 100% of complaints about labor shortages are really complaints that the intersection of the supply an demand curves are at a point that results in purchasers of labor making less profit from whatever they are buying that labor for than they’d like, and laborers making more than those employers would like.
And "companies" could be replaced by "people" and "labor" could be replaced by "stuff"...
The case of COBOL is of interest as there was a wave of articles this year suggesting there was some sort of anomaly on the market: tons of COBOL programs and not a soul alive to maintain them.
> The case of COBOL is of interest as there was a wave of articles this year suggesting there was some sort of anomaly on the market: tons of COBOL programs and not a soul alive to maintain them.
There’s probably something more like a legitimate short-term shortage in that case, because you have lots of immediate demand for changes (because of urgent business process changes) to stale legacy systems, so you really don’t have the luxury of waiting on long-term corrective mechanisms like retraining, price signalling through the pipeline for workforce entrants, etc., before the value opportunity is missed. COVID-19 and the resulting (many probably short-term) legal and business changes created a number of market anomalies of that kind.
Do note this kind of wave of articles is recurrent, is not tied in general to COVID-19 (might be in the current situation, but I've seen it at least once or twice a year), and has been almost always false. "False" in the sense that no, learning COBOL is not such a great career choice to enter a life of wealth and untapped riches.
If they paid well enough, your average working programmer would flip to COBOL for a pay raise. Once you've learned a few languages, you can solve problems in any language. It's just about having the manual and maybe an overview of available facilities so you don't have to read all the docs upfront. The syntax doesn't matter for data plumbing applications. COBOL is as good as BASIC as good as Java as good as Python etc. You might prefer writing Python (or Haskell, Clojure, Rust, C++, Go, Scala, Kotlin, whatever is en-vogue these days) because it is more concise, but if you can effectively hack in one language you can do it in COBOL too with a little effort.
I'd happily take a COBOL job for $250k + benefits and a 3% annual raise. That's hardly a crazy salary either. It's still a substantial discount over what a lot of technology companies pay, and likely inline with what most mid-level managers at banks and insurance companies earn already.
But COBOL jobs don't pay anywhere near that kind of coin, and they likely never will in my lifetime. The systems in place are solid enough that they can survive the resolving door of shitty, underpaid contractors who are hired to work on them. Nothing every improves, but it also never gets worse.
Same here. Working with a crappier language in return for retiring earlier is an acceptable trade off for me. Even if after a decade of working in COBOL I became unable to find another IT job, I wouldn't care, because I'd be already happily early retired.
Out of curiosity I just made a short search for COBOL jobs in my area. The few I found actually pay less than my current Java job.
"these days"?? COBOL has been available on Windows since Windows 3.1, and was even a commercial success on DOS in pre-Windows days. Yes, it was principally used in finance on mainframes, but the mini- and micro-computer implementations were fully ANSI standard, and included extensions for CICS and other mainframe stuff.
(I worked on DOS COBOL runtime support, then OS/2, then Windows ...)
>Let me tell you a secret. It doesn't work for non-programmers. The complexity of "Z = X + Y" is no more or less than "ADD X TO Y GIVING Z", and bugs will happen at the same rate with either syntax. The added verbosity will only annoy you.
Not to mention that verbosity often distracts from meaning, leading to more place for bugs to hide.
The reality: I've never met a really wealthy COBOL programmer -- or rather, one who was wealthy because he/she knew COBOL.
The pay is at the intersection of "knows COBOL" and "knows the problem domain inside out". The problem domains are not something most people would ever have been exposed to without getting in in the first place as COBOL programmers.
I don't disagree with you. But note most people learning COBOL won't get those high-paying jobs; they'll instead end up maintaining legacy and boring corporate systems. And COBOL isn't a particularly interesting language to learn: in the spectrum between boring <--> cutting edge, COBOL lands on the far side of "very boring"!
> COBOL jobs are not particularly well-paying, and there are young people learning it, and no, they don't get awesome paychecks.
But say this to non-programmers, and they vehemently deny it's true. And always cite a friend of their neighbor who made it good from COBOL. It's like they need to believe there's a shortcut out there to sure wealth as long as you're smart and work hard.
Whose hatred? I don't think I've seen anybody really hate on COBOL, it's just mostly irrelevant for modern programmers and people like to mock the FULL CAPS ULTRA VERBOSE SYNTAX (something that COBOL programmers themselves routinely do, see ADD 1 TO COBOL GIVING COBOL).
I disagree with your definition of modern programmers. I mean, we still emulate VT100 terminals on our 2020 MacBooks (poorly), so the implication that everything old must be renewed is - in theory - good, but COBOL is probably not the first thing that comes to my mind here...
Modern COBOL does not enforce CAPS LOCK anymore though - and you can even skip the 7-columns indentation if you wish!
To be clear I wasn't making a judgement of value, I was just stating matter-of-factly that I've been a professional dev for over 15 years and while I did occasionally encounter some more niche languages I haven't actually bumped into a COBOL listing if I wasn't specifically looking for it. Fortran, Scheme, Haskell, Erlang, Modula? Occasionally. COBOL, never.
Neat, I’ve been down a rabbit hole with many of Wirth’s languages a few times, but never properly learned them. I think I tried to get some Modula 2 or Modula 3 gcc frontend to work a while back with little luck.
COBOL put me through undergrad, so I'm ok with it.
And, it was developed long before a lot of modern compiler theory was even thought of, so it's going to be a little unfamiliar to those used to "modern" languages.
This seems like a great candidate for a future Advent of Code! Old languages have a special place in my heart, so doing Advent of Code with them is kind of fun.
I'm doing this year's in UniVerse BASIC[0] which traces its roots back to Pick[1] which is only six years newer than COBOL, but manages to be less well-known.
If you're able to create a graph structure with references/access/pointer types or whatever COBOL uses you can have records with contents similar to:
record Bag:
string : Description
array of Bag Pointer : Children
array of Integer : Count
Where the indexes into the two arrays correlate. Since, as you parse, you don't know where the children may be, you can use an array to store the bags as you read them in. And in a second pass construct the graph proper. You may also want a set of pointers up to the bags containing a bag, but it's not, strictly, needed.
If I were doing this year's in C, I'd have done something like that since it, also, doesn't have a built-in hash table/dictionary.
First, UniVerse BASIC isn't the old BASIC like you'd find on an Apple ][ or C-64, nor is it the QBasic you'd find in MS-DOS. It has its own unique features, such as dynamic arrays.
Second, I'm taking advantage of UniVerse features where they make sense. When I do this I document it since the code only has a portion of the solution. So far, I've done these for an alternate version of day 4 and for day 7. In particular, I used a UniVerse file in place of a hash table for day 7.
Thank you for sharing! I tried this one year on one challenge, but was barely familiar with writing COBOL programs, so I didn't continue with it. But after seeing your repo, I might go back and try this alongside the Lisp and Python I've been doing this year.
And they say only Rust makes it to the front page of HN.
More seriously is this release particularly notable in the COBOL world? I know very little about the language and I find it odd to find the Changelog of a minor release at the top of the frontpage.
GnuCOBOL seems to be the de-facto standard COBOL implementation on Unix-like platforms these days, so (at least) it is a notable software. They seem to have no actual blog, so the changelog is the best news link I could come up with...
If you're first programming job is in COBOL, then getting that second job will be a problem.
The technology stack you choose early on is pretty vital to your career growth. A common way of growing your salary early on is to switch jobs every few years. And to do that successfully, you'll want to have a valuable skill-set that hiring managers are looking for.
For all the talk around here about "fundamentals" being what makes you employable, my experience shows that is not the case. For example, my company doesn't interview candidates without Javascript on their resume because they want people who know and have worked with it. I think it's a dumb policy, but I have no control to change it.
I say YES do it, learn COBOL and Mainframes, don't listen to others who say Mainframe is a thing of the past, it's here to stay. Just talk with leading positions in Insurance/Finance government maybe?, they are more then happy to find someone who is motivated and eager to learn, AND they have the money and time to support and build-you-up (Training mentors certs licenses etc.).
I would say from a career path perspective this world seems to offer some advantages in the area of cumulative knowledge acquisition. Whereas the typical career path in The Enterprise one is faced with technology churn every few years.
Being in The Enterprise, I find it quite frustrating dealing with the new shiny every few years when there's rarely objective analysis behind being made to do so.
Yup. You can get some hands-on using the Hercules emulator, but it's running old versions of the OSes due to licensing. That can give you the basics, tho, because Mainframe OSes tend to be pretty stable over time.
Beyond that, IBM has a ton of educational resources you could leverage. At one time they had a program where you could get an account on a mainframe, but I don't know if they do that any more.
Udemy has some mainframe/Cobol tracks. I assume other on-line training does as well.
There are a number of colleges that have mainframe focused degree tracks (Columbus State University has one). These days, you could probably find one that does it on-line.
In that case, wouldn't it be better to review which programming job positions pay decently and are open where you live -- or are willing to relocate to -- and see which languages they are asking for? It's unlikely that COBOL will be your top choice.
Otherwise you're "putting the cart before the horse", so to speak. Plus listing COBOL in your resume can have a detrimental effect in future job interviews, at least at some companies.
Because I already know: C, C++, Obj-C, C#, Php, Lua, x86 ASM, ARM ASM, Linoleum (some ASM-like esoteric languagE), BASIC (not VB), Java, Python, JS, MushCODE (it is derived from LISP), SQL and some application specific scripting languages.
I started coding when I was 8, I am 32 now, and in my government-issued employer list, I had zero employers.
My dad knows COBOL and MUMPS, and kept talking about how horrible they are... but maybe I can get a job if I try these.
If you're fluent in all those languages then I doubt COBOL will be your breakthrough. Those high earning COBOL jobs don't pay so well because the programmers are hyper intelligent, they pay well because there's not that many people left that have experience running mainframes. If you've only just mastered COBOL, you'll probably be last in line for any good COBOL job out there.
With a portfolio like that, you might want to look at why you can't get a job. You sound capable enough on the technical front, so there must be something else that's preventing you from advancing your career.
If you're having trouble landing a job even though you know all those languages, COBOL won't be the magical solution. It's likely your problem lies elsewhere...
Getting a job or building a career in software development isn't about the languages you know. Your list is pretty broad and COBOL probably won't help.
It's what value you can provide with those that counts.
One of my earlier companies started with a policy
against hiring folks who just knew PHP, even though that was our main language. We wanted folks who knew SQL, some JS, maybe some C or something to prove they were well-rounded and could think about tech as a whole.
We dropped that policy when folks started coming in with _just_ Ruby on Rails under their belt. They were destroying our project-based interview and blasting out projects in weeks that typically took us months. And we found that we could easily teach them the SQL they needed when they needed it.
I'm not saying it's _just that easy_ but if a dev hits my interview process and shows they can understand my customer's needs and build out a solution to those needs quickly, I _very much_ want to give them a job.
Quite a few companies have specialized in migrating COBOL to C# or Java code, so I’m not surprised. I wonder why they choose those languages as one-trick ponies though. Seems like the “we only have a hammer” problem.
I guess because it's very very likely the rest of the custom internal systems is already written in one of those languages, they are both used a lot in such contexts.
And you will not have to deal with the ego of the current programmers that pretend they now everything about any existing programming language, paradigm and technical stack (where I include myself and because that is what is demanded)
On the one hand we love and respect Admiral Grace Hopper and on the other hand the COBOL language she is credited with is scorned. I always thought this was somewhat unusual.
It was a challenge I was able to do in about 4 hours of code I didn't find that much harder to program in a Cobol (given that you use the right IDE, I wrote it in Gedit and the identation was a pain at first)
Ah COBOL, oddly enough I started my first dev job in COBOL in the banking industry(I'm in my 30s and started my professional coding career in my 20s), I have mixed feelings about it...it's a weird language but it has it's place, I wouldn't advise anyone to jump into a COBOL career path unless you are doing it for a job and a job alone.
I would kill to get a personal mainframe though. Read a story some time ago about some guy who snagged one from a government auction. Sadly they never have anything cool when I look.
I remember that story. I don't think he ever got it working. There's a lot to getting a real mainframe running, starting with some onerous licensing terms for the software. And the cost to power one would be ugly.
There were some actual 'personal mainframes' made by IBM. The PC/370 was a PC or PC/AT with a set of ISA bus mainframe processor addin cards. The PC became the I/O processor. The PC/390 was a later version based on a PS/2 running OS/2. All long obsolete now.
> He and his old computer friends played around with some applications that were on the platform, and even made an FTP server that put some data on the internet.
Otherwise if you live in the Midwest...uw oshkosh use to have one for free. The stipulation was that you had to remove it from the campus. And it weighed 3 tons
I'm afraid of SF links not even because the malware thing from a few years back, but because there's a 50/50 chance "the project that looks like it will perfectly solve my issues" is just straight up abandonware.
I tried writing my own little accounting app in GnuCOBOL. For fun, believe it or not. It didn't take me too long to bow to the inevitable and rewrite it in Perl.
I had a look at it a few years ago, and decided it probably wasn't suitable for my purposes. Interestingly, I see that it was updated in June of this year. The original code stretches back decades, IIRC, and has been deployed in a commercial setting. I spoke to the author on one occasion.
I have a casual interest in retro stuff, so Cobol was kinda interesting to play with for awhile, but in the end I decided that it was hopelessly impractical.
I’m curious too, my understanding is that 90% of COBOL work is done in older mainframes (or ported from older mainframes to newer ones) and likely uses whatever IBM compilers. I don’t think I’ve ever heard of GnuCOBOL being used outside of learning.
In my (very limited) z/OS experience, COBOL by itself is necessary but not nearly sufficient. COBOL code is used inside a framework of highly proprietary software and system services:
- DB2 (database is builtin to the mainframe)
- GDG (Generation Data Groups, versioned file system)
Probably not hard for you to guess that my experience is limited entirely to enterprise batch processing and data warehousing. I've heard of CICS, but only as a nasty rumor.
I used to wonder why so many different programming languages and why so many opinions about them.
After couple of decades i learnt about Domain Specific Language (DSL) concept.
I started out coding COBOL and some assembler after learning Pascal and others during education. I now code in python, c, c# or whatever us best fit.
My opinion and experience suggests these are all DSL just as COBOL was probably one of the first. It is excellent for business logic and business transaction oriented data processing.
Like all languages and tools the in output is mostly unreliable garbage in the hands of the ignorant and unskilled/ill-disciplined.
I don't think the popularity of languages is as much to do with their technical merits add it is about the community that builds around each. Each community if like a tribe and the tribes have norms arising from their environment and common needs.
Wow...Nevada Cobol. That brings back some memories. We were kinda shocked someone could fit it on a CP/M machine. Had a friend who learned enough using Nevada at home to get a job doing VM/370 Cobol for an airline and ended up becoming a VP by the time he retired.
I think I may have started a course in COBOL many years ago.
Wonder if would be worth learning it now?
There is a lot of COBOL code that needs to be maintained.
Well, there is the chance of enabling creative new insurance or banking products, if you cna bend the legacy in interesting ways. The chance is technically there, if management allows is the other question ;)
Is maintaining legacy spaghetti code written by below average programmers something that strikes your fancy? If so, COBOL might be for you -- but bear in mind there's no shortage of legacy spaghetti code written in more modern & marketable languages! :P
Having spent much of my time in Fortan 90 the last couple of months - I'm going to have to go ahead and disagree with you on this one. You know all these people saying "when will I ever have to write mu own hash table?" Well, when you start working in Fortran.
Do you have some weird constraint where you can't use 3rd party libraries? Yeah, hash tables aren't built into the language, but libraries to provide them are all over the place. See for example http://fortranwiki.org/fortran/show/Hash+tables. Or you could a C function. Or C++ in some compilers.
I can use them in the sense that I'm allowed to, but the compiler that I use can't compile FLIBS nor most of the libraries in your link; and the ones it could compile, I had to adapt, requiring understanding of what a 'hash table' is beyond just 'it's a key to value mapping'. I didn't want to make my post all about my Fortran problems, but I still think knowing the basics of fundamental data structures is foundational knowledge.
Well, sure knowing the basics of fundamental data structures is foundational knowledge. But you were complaining about lack of hash tables, and it seems what you really had was compiler issues. That's not something unique to Fortran.
F90 isn't bad, try F77. F90 and on you had more options with the layout of your program so that it was actually sensible. And you can use recursion without having to check if your compiler supports it. And reentrant functions.
But the built-in types are collection types are anemic, it's similar to C in that regard. It's a relatively low-level language compared to other high-level languages. But if I were doing math/simulation stuffs, I would definitely consider using it again.
Just, please, no more embedded programs written in Fortran. That was a bad idea (unless it's doing complex math like for the radar system).
Me too... the lack of decent non-array containers is frustrating. The string handling is also painful (seemingly TRIM everywhere). I've also hit several compiler bugs trying to use fairly new features.
I've never seen COBOL described as cool before, and I must respectfully disagree. COBOL is horrible and uncool -- I should know, I used in one of my first jobs.
Personally I don’t think it is stable enough for a long lived service. But opinions differ. Might be worse if the author reinvented pandas manually, too.
