Live data from Hacker News

Learning COBOL: A Journey for the Modern Programmer

monadical.com

51–60 of 63 posts

Re: Learning COBOL: A Journey for the Modern Programmer

#51

Out of curiosity, does knowing COBOL pay well in 2021? It seems COBOL programmers are in critical demand and free market economics should mean that COBOL programmers get paid premiums. I would research this by myself, but not really sure where to start - and googling “COBOL Developer Salary” leads to results in the 80-120k range (which is no small number, but not significantly different from a modern language develop…

Senior mainframe programmers seem to get paid less than entry level java/SQL programmers where I work at.

Re: Learning COBOL: A Journey for the Modern Programmer

#52

Earlier quoted context omitted.

This. On a different language, but same mindset. System is many years outdated and no one understands it. Get a ticket. “Fix all the problems” Me “Umm okay. Hire 20 people and give us 3 years.” Them: you have a week by yourself. 14 months later their standpoint is it’s always one more week left. I can’t tell if they even see the absurdity anymore.

Do they have a critical dependency on it?

If it doesn’t work they go out of business.

Re: Learning COBOL: A Journey for the Modern Programmer

#53
post #30

I suppose it's again that time of the year when there's a flood of articles trying to convince people that COBOL is worth learning, that it's been updated or that it pays really well, and that there are lots of hidden opportunities for you to make big money working with COBOL! Those of us who actually worked with COBOL aren't fooled though. It bears repeating: COBOL is a horrible language and it's often used in legac…

It also doesn't seem to pay that well. I would expect too earn 2-4 times as much as a Java dev but that doesn't seem to be the case.

Re: Learning COBOL: A Journey for the Modern Programmer

#54
post #35

Anyone attempted to write a COBOL code generator in a more comfortable language? Or isn‘t code generation the problem, rather the reading/modifying legacy code?

> Or isn‘t code generation the problem, rather the reading/modifying legacy code?

Its this. If someone is doing greenfield z/OS development, I would assume they are probably using a more modern language (IBM highlights Java and C/C++ support on z/OS), not COBOL. But there is tons of legacy code in COBOL – much of it that was never well-documented. Sure, there’s fewer available COBOL programmers, but in many cases the orgs with these systems have also lost most of the people that were serving as living documentation, which is not great when the system is operating in near-steady-state, but becomes a critical problem when it needs new changes. So, the COBOL programmers they tend to need are for code archeology, temporally-displaced mind-reading to understand the original intent of code and diff it with emergent requirements, and maintenance on legacy systems.

Re: Learning COBOL: A Journey for the Modern Programmer

#55
post #30

I suppose it's again that time of the year when there's a flood of articles trying to convince people that COBOL is worth learning, that it's been updated or that it pays really well, and that there are lots of hidden opportunities for you to make big money working with COBOL! Those of us who actually worked with COBOL aren't fooled though. It bears repeating: COBOL is a horrible language and it's often used in legac…

I've noticed that people only speak highly of COBOL, as a technology, when Grace Murray Hopper's name occurs nearby.

That's all that I need to know about COBOL.

Re: Learning COBOL: A Journey for the Modern Programmer

#56

Earlier quoted context omitted.

>"... I work in a city with literally thousands of former cobol developers who's jobs were offshored over the past two decades." I was intrigued by this. Can you say what city and why there are so many Cobol developers there?

Any city with telecom, airline headquarters, and financial services. This one has all three. Could be Chicago, and others.

Interesting I always associate COBOL with banking I didn't know it was as equally entrenched in airlines and telecom as well.

Re: Learning COBOL: A Journey for the Modern Programmer

#57
I found it interesting that the author found COBOL's use of line numbers strange and chalked it up to its origin in the punch card era. While that may have been part of it, those of us who learned programming via BASIC in the 1980s were very used to line numbers even though we never saw a punch card.

Re: Learning COBOL: A Journey for the Modern Programmer

#58

I found it interesting that the author found COBOL's use of line numbers strange and chalked it up to its origin in the punch card era. While that may have been part of it, those of us who learned programming via BASIC in the 1980s were very used to line numbers even though we never saw a punch card.

> I found it interesting that the author found COBOL's use of line numbers strange and chalked it up to its origin in the punch card era. While that may have been part of it, those of us who learned programming via BASIC in the 1980s were very used to line numbers even though we never saw a punch card.

BASIC is also from the punch card era; it is only 5 years newer than COBOL (1964 vs 1959).

Re: Learning COBOL: A Journey for the Modern Programmer

#59

I found it interesting that the author found COBOL's use of line numbers strange and chalked it up to its origin in the punch card era. While that may have been part of it, those of us who learned programming via BASIC in the 1980s were very used to line numbers even though we never saw a punch card.

> I found it interesting that the author found COBOL's use of line numbers strange and chalked it up to its origin in the punch card era. While that may have been part of it, those of us who learned programming via BASIC in the 1980s were very used to line numbers even though we never saw a punch card. BASIC is also from the punch card era; it is only 5 years newer than COBOL (1964 vs 1959).

BASIC was designed as an interactive language on the Dartmouth Timesharing System rather than batch, though. It was assumed that the user was at a terminal (probably a teletype given the era) and could interact in real time with the computer rather than punching cards to be handed to an operator and receiving output later. The line numbers were there to aid editing code as a replacement line could be entered using the same line number as an existing line. This tradition carried into the home computers of the 1980s as they generally didn't use text editors as we know them for editing BASIC code.

Re: Learning COBOL: A Journey for the Modern Programmer

#60
post #15

Earlier quoted context omitted.

My take on visual programming is it's easier to start out with, but you're quickly better off using a conventional language once you reach a certain scale or you need to manipulate your program in certain ways. Almost every time I see an expression builder in a UI, I think it would be better off with SQL syntax and autocomplete because the dropdowns get old fast, and SQL expressions aren't that hard.

Some SQL expressions can get extremely complex.

True, but imagine that in a query builder GUI.
Post reply on HN