Your big problem with COBOL will be staffing - everyone knows that scarcity plus demand means that COBOL programmers routinely command 7-figure salaries, and even if your funders can pony up the required cash, getting those guys away from their private islands that they purchased with their Y2K booty is going to be tough.
What is high paid is not the ability to write COBOL, what is being highly paid is understanding the 40 year old application building the foundation of the insurance or bank. If you understand all the implications of code changes there, you are worth a lot. If you need oversight to not break anything (hardly any tests etc.) you a worth a lot less.
Spot on. I see people talking about learning COBOL or not, but as you say that's not so much the point. You really need to know how ancient mainframes work. A programmer can pick up the basics of COBOL soon enough, but understanding the ins and outs of zOS and the likes? Much harder, especially the more recent your tech knowledge is. Approaches to software and systems design has changed dramatically since the IBM mainframe days. If you want to make money working on old software just learn Java EE or .NET Framework or something!
I know a guy who used to write COBOL at IBM. He was apparently quite good. He now drives trucks for a landscape supply company. I told him that he should look into COBOL jobs again so he did some research. It seems that the actual number of available jobs is a lot lower than the hype would suggest.
my understanding is that companies with COBOL are big instituions with people not much interested in "career" but in "stability". So those old programmers stay there until they retire (nothing wrong with that). So they keep up the COBOL system. Once they get older management thinks about replacing the COBOL system with something new. If it's really expensive, a new system is built around the COBOL system with new technologies : report by report, DB by DB, etc. until then old system can be unplugged. It takes 10 to 20 years to do so. Nothing unbearable for a big corp.
The way I’ve always heard it is that it’s somewhat bimodal.
You got people with many decades of experience who can, as independent consultants charge an impressive price for there time. Then you get people who were maybe bait and switched or took what they could find working as a low paid contractor or developer for a company that doesn’t pay the best.
I placed second in a statewide (Texas) COBOL programming contest in high school. This was the late 90s. While in college (which I started early), I kept having people track me down to offer mid-six-figure salaries. It was very tempting. It was pretty surreal (again, this was pre-web boom, and starting tech salaries were mid-5-figures) as an 18 year old having people offer me $400k/year.
Just saw this now. Not sure you caught the context, which was implied by the poster above. This was 1998, when loads of major corporations were terrified of "the Y2k bug" which was talked about in very apocalyptic terms. There was a scramble to find COBOL programmers, because it was feared that the majority of the bugs were in long-running COBOL systems, but most competent COBOL developers at that point had retired. It's true that I didn't follow up with those folks (other than to say, "no thanks"), but being contacted by multiple recruiters promising six-figure salaries was very much a thing.
The only high-level language more proven is Lisp, but most of the procedures are written in lower case so I don't think it's serious enough to be a business oriented language.
Also, business people don't like things to think for themselves, so Lisp would be risky in that respect.
Not Fortran, in which you originally needed to SHOUT, though you couldn't go SHOUTING? It was good enough to implement one of the earliest RDBs, after all, which sounds business-like.
You have a sarcasm tag, but I've been waiting for this release!
Just think about it, I can run my PI servers on COBOL without the intricate, ever-failing dance of dependency from externally sourced, crufty packages, whose security holes eventually get opened wide by the latest DawnSpreader or Mousy Trick-Track exploits. /s
Wait... maybe there is something there after all...
We have a bank in South Africa called Capitec, and they were sort of considered a "startup" bank a few years ago, doing things better and more efficient. But they are using COBOL regardless (+ other cloud tech of course as decorations)
Yeah, but the language is largely irrelevant here right (assuming the intent in posting this was "look a free open source cobol"). The difficulty in cobol systems is that IBM Mainframes are really cool, but insanely expensive and locked down. I can put GNUCobol on my laptop and learn hello world, but I won't have access to the mainframe transactions, which is probably 99% of the problem in learning a Cobol system.
It gets even worse: I got stuck for a year once working on COBOL software that only ran on Solaris, depended on Micro Focus's buggy and slow $3000 compiler, did binary searches across flat files and depended on Unix calls like mmap(). I got it up and running long enough to see how the code worked so that it could be rewritten in Pascal (this was chosen because that's what the guy I was working with preferred).
COBOL is a terrible, verbose language that doesn't even have local variables. It belongs on the ash-heap of computing history, not in any project that should be maintained today.
Indeed: mainframe COBOL programs often invoke transaction processing and data management facilities (using “EXEC CICS,” “EXEC DLI,” or “EXEC SQL” statements, for example) that aren’t part of the standardized COBOL language.
There are commercial software packages for re-hosting mainframe applications to other platforms. These typically provide not only COBOL and PL/I compilers but also functional equivalents of CICS, VSAM, JCL (JES2), and other mainframe system software.
Thanks for the confirmation and the additional background information.
So an open-source/free version of one of those "re-hosting" packages sounds like it would be useful for someone wanting to learn about cobol + mainframe development, but I can't imagine that ever happening (demand can't be too high) lol.
I heard COBOL is used a lot in large (governmental) organizations. What are the compilers commonly in use in those places? Is this GNU impl commonly seen there?
Their variant of COBOL has a number of extensions beyond the regular standard in GnuCOBOL. One that springs to mind is around data serialisation and file formatting.
They also implemented an API layer for access from more modern stacks.
Incidentally, if you're interested in getting into software development, I believe the DWP in the UK are still currently taking on apprentices to work on the COBOL-based systems in the department - I think they also get training in other languages too - perhaps JS, Ruby or Python?
Large organizations you speak of that use COBOL are mostly insurance and finance megacorps, and some government, that were (and some still are) deep in the pockets of various mainframe vendors. Vendors distributed their own compilers with some tweaks to the language, like IBM.
It's extremely rare to see FOSS in such legacy systems. The push for FOSS in large corporations has been coming from the for newer stacks, designed by newer developers.
DIGITAL, IBM and HP typically supplied COBOL compilers with their relevant big iron systems and a lot of time the actual code base will be tied so closely to a greater framework provided by/for those platforms that just being able to compile COBOL on an different environment is the least part of the migration process.
Heh, ironically the reason I couldn't get into programming when I was younger is that the only programming book in my local library was COBOL; and the compiler CD had been stolen.
Cobol itself is pretty evil to learn and not comparable to most c-like languages. I think the fact that it was so intimidating set me back about 10y on learning programming as I always just assumed it was too hard.
It wasn't a very interesting language back then, and it definitely isn't one today, so in my opinion nobody should learn it unless they have a really good reason (and no, you won't make big bucks working with COBOL).
Source: I have experience with COBOL banking systems. Horrible, horrible programming language.
I worked for a company that 'on-shored' COBOL and RPG programmers. Many of the Senior Engineers were called out of retirement and were training up the younger folks hired. They placed their main office in a rural area which kept costs low and, for the area, they were paying great money, particularly for the entry-level engineers.
To your point about not making 'big bucks', you're right, but it's nothing to shake a stick at if you really want to get after it.
Agreed: any job is good if you need the money. My comment is mostly a counterpoint to the usual shill articles we get about twice a year on HN about the "great opportunity" of learning COBOL today because of an alleged programmers' shortage and because there are big bucks there... allegedly.
Those of us who actually worked with COBOL know it's an awkward language used for legacy systems, and which should be avoided -- and definitely not learned now -- if you can get any other programming job.
No, COBOL is not "fun". No, it's not a good programming language. No, it's not the best money making opportunity. No, COBOL programmers aren't making lots of money. And the downside of getting a COBOL job is pretty big: you have to use COBOL.
This week we already had three COBOL related posts to HN (that I saw), one of them of the "you should learn COBOL" shill type.
> Are there many public COBOL code bases? From a quick search, I'll I've found is ...
The community of COBOL researchers is growing exponentially! [0] It's best to start with COBOL development in order to be an expert when COBOL's use really explodes.
TBH, the jobs I held in the late 90's and early 2000's where I was a COBOL programmer were honestly some of the most challenging jobs I've had. There were large systems that nobody understood and hadn't touched. I was really surprised to find banks relying on systems that hadn't been touched in 10 years.
But let me ask. Would anyone hire me having 6 years COBOL experience from late 90's to early 2000's?
I'm trying to picture the Venn diagram of people who want to use COBOL, people who care about using COBOL for free, and people who would prefer using a free Gnu COBOL to a free IBM COBOL.
A bit longer than 2 decades ago, I got MicroFocus NetExpress to use DirectX, just for fun. Never did anything relevant with it, but it was possible (on Windows)
Really? COBOL is younger than neural network algorithms and seems like a prime language to write neural networks!
The first artificial neural network was invented in 1958 by psychologist Frank Rosenblatt. Called Perceptron, it was intended to model how the human brain processed visual data and learned to recognize objects. Other researchers have since used similar ANNs to study human cognition. [0]
COBOL is a high-level programming language first developed by the CODASYL Committee (Conference on Data Systems Languages) in 1960. [1]
A COBOL-like neural network simulation language based on layer macro definition [2]
Perceptron in COBOL [3]
My first program in COBOL, a single neuron neural network. [4]
[0] https://www.computerworld.com/article/2591759/artificial-neural-networks.html
[1] http://www.csis.ul.ie/cobol/course/COBOLIntro.htm
[2] https://ieeexplore.ieee.org/document/714089
[3] https://github.com/victorqribeiro/perceptronCobol
[4] https://www.reddit.com/r/programming/comments/gt8cao/my_first_program_in_cobol_a_single_neuron_neural/
