The Inevitable return of Cobol
blog.hackerrank.com
blog.hackerrank.com
The language itself isn't that bad. There are a lot of quirks given how old it is (variable names being limited in size, file name being only 8 characters long, file-based scope, etc), but once you learn them it's really not that bad.
The best thing about the language is how it enforces a particular programming style. You have to define ALL variable and external data sources before you're able to use them. And when you get to the meat-and-potatoes of the program, a certain style is primarily used: open external resources (files, DB2 tables), check for IO errors, process the data, close the resources. Makes it easy to grok what's going on within a program (even if that program is older than you are).
The biggest challenge that I see for new COBOL programmers is learning all of the tools you'll use for your job. On the IBM zSeries Mainframe that we use, there are a TON of tools that we use to monitor our batch/CICS online programs. But that, like everything else, will take practice.
In a saner world, nothing. Someone hiring for COBOL would see a candidate who knows a handful of other programming languages, some database theory, and a little bit of other experience and hire and actually train them.
Source: I worked for a bank in my youth, which involved writing COBOL.
Endevor for version control on Z/OS.
The reason they tend to still exist, where they do still exist, is that businesses don't want to dedicate the budget to the replacement. But that also means that they don't want to dedicate a huge budget to maintenance, either. If COBOL actually gets rare enough that COBOL devs start getting high-end wages, it makes the "replace this thing" option look that much more appealing, which pretty much puts a ceiling on the demand for COBOL devs.
If you are a purely mercenary developer, don't learn COBOL, because it's not where the money is.
On the other hand, the only COBOL shop in town pays meager wages and is considered to be the place where your career goes to ddie.
I always have wondered what it would've been like if she had stuck with that instead of going off to live in the woods of New Hampshire.
Well I had some work experience as a developer from a startup doing web stuff.
If you're in this mostly for the money, then sure, learn COBOL.
Then again, being stuck in crappy, uninspiring code all day and then getting to use something interesting and exciting in your off time can sometimes make the day job all that much harder to handle...
I fully agree that no overtime is great -- that's why I'm not arguing anything about startups! -- but when you realize how many hours a day you spend in your day job, working with something that sucks cannot be compensated by a hobby. For me, at least. I fully understand someone could find the trade-off acceptable.
I've also done (and am doing) the solo hacking on startup stuff. Getting motivated for that can be really hard.
Isn't that such a weird feeling when you're in tech? :)
I am not a COBOL programmer, but I imagine taking a COBOL gig is like stepping back in time to the days of IBM, mainframes and suits at the office.
Finance is however a huge field on its own. And a huge part of the work is implementing new regulations.
If I end up getting bored, I know multiple other languages quite well. And if I decide to leave the finance sector, having a job as a developer on a bank is a positive thing here.
(EBCDIC - you know, the un-ASCII, designed after ASCII specifically to be backwards-compatible with the integers punched on punch cards.)
https://en.wikipedia.org/wiki/COBOL#COBOL_2002_and_object-or...
If COBOL programmers were gone, never to come back, they would have to port- but the market worked its magic.
I'm imagining that these folks would be non-programmers who are identified as having good reasoning and structural thinking, and who could receive a pay bump by moving into a development position. I don't expect that existing developers would want to move away from their current skillset trajectory and I think that route is probably not a fruitful one to pursue.
It remains to be seen if this will be a successful endeavor.
Take both languages and their similar platforms and throw web interfacing, transformation, and such, and you can end up training even those who know the basics. With RPG the advantage it has and disadvantage is that there is no standard; its all IBM and their developers who determine its course. Modern RPG can look at lot like C/Pascal with no fixed columns and the like.
Schools tend to focus on whats cool or strictly PC centric languages but there are many sources of skill, all over seas. Some are contracted out and some come across and take positions that could have gone to local talent if they had received exposure. Large machines will never truly die out and business logic that has a great deal of investment behind it is not easy to part with.
One area of COBOL and RPG; and similar older languages; is their well developed handling of business math. You know exactly what to expect.
It this is not the case, then the recruiters are doing a bad job winning the hearts and minds of job seekers and those try to follow hiring trends.
Fortran is also alive and kicking, also in narrow but well-entrenched niches. Modern Fortran became a nicer language, though, then e.g. Fortran IV or 77.
Bigger fun will begin when C will be universally seen as a legacy language, inexpressive, full of pitfalls and undefined behaviors, etc, but huge amounts of important C code will have to be maintained without a chance of rewriting it in a nicer language in sight.
All of that is densely packed business logic with very little other stuff. It'd be painstaking to convert to more modern paradigm, without dropping a single feature on the floor. Convert all the existing data and shim all the interfaces as you convert piece by piece.
Importantly, the whole effort has no intrinsic business value, is unbounded in scope, risky and tends to paralyze the kind of on-going small maintenance that kept the system current with changes in practice, accounting rules, tax law, HR processes, etc.
Finally, Gary and Sue who were the last ones who actually knew all the pieces of the stacks and how they fit retired in '97 and '03.
Is there anything like an IBM System 36 emulator out there?
Then again my Amiga at the time had about as much ram as the IBM/36.
Idealist: Why don't enterprises move to modern and stable systems?
Pragamatist: Literally billions of small programs/processes are written in this and they work reliably.