Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

COBOL: Thinking about it wrong

gcn.com

Post reply on HN
Print view View original

61–70 of 116 posts

Re: COBOL: Thinking about it wrong

#61

Post by [deleted] »

JohnFen wrote: post #25
benjaminpv wrote: post #13

COBOL was actually in the CS curriculum for my university, a fact that several of my friends brought up when the 'COVID is prompting a real need for COBOL programmers in light of the need to change benefits rules and unemployment!' stories were a regular feature on the nightly news. 'You should do it, man!' Yeah, sure. I'd already suffered through the liquidation of my entire department in 2018, the prospect of the h…

> the additional stain of 'oh, what've you been doing? Cool, popular JS frameworks? No, COBOL? Pass.' on my CV That's pretty much the last thing that I'd worry about. A company that evaluates potential hires that way is not a company that's worth working for, in my opinion. And most companies I've encountered wouldn't think that way.

[deleted]

Re: COBOL: Thinking about it wrong

#62

Post by poulsbohemian »

SoftTalker wrote: post #59
BlandDuck wrote: post #36

I have seen the COBOL issue come up a number of times, and I just don't get it. Am I thinking about this wrong? COBOL seems to be a straightforward language by modern standards. Any programmer with experience with imperative languages should be able to pick it up. Learning the language itself cannot be a real barrier. The barrier seems to be the enormous amount of legacy code that has to be digested and understood. B…

COBOL the language is pretty simple, you’re right. I learned it in a few weeks in my first job out of college in the early 1990s. Even today, you can grab Gnu COBOL and learn the language. What takes longer is understanding the whole architecture of mainframe software. JCL, CICS, etc. It’s quite foreign to anything you learned about programming for Unix. And there really aren’t any free or open-source resources to le…

>What takes longer is understanding the whole architecture of mainframe software. JCL, CICS, etc. It’s quite foreign to anything you learned about programming for Unix. And there really aren’t any free or open-source resources to learn it, as far as I know.

This could be what you mean, but isn't the problem here one of access? I know just enough about JCL, CICS, etc to be dangerous, and never found any of the mainframe systems to be that difficult to learn (it's all basically batching, queueing, scheduling...) but without access to a mainframe, it's kind of a non-starter to actually get hands-on with any of this stuff. IE: thanks to the multi-decade shift to open source, we've got generations that have that skill set because it was accessible.

Re: COBOL: Thinking about it wrong

#63

Post by drewcoo »

COBOL (COmmon Business-Oriented Language) was designed by Grace Hopper to make it easier for business folks to write code.

https://www.zdnet.com/article/cobol-grace-hoppers-gift-to-th...

That goal a flop, so programmers had to take over.

Wasn't there a Cucumber/Gherkin story here really recently? That grew out of Fit/Fitnesse (from Ward Cunningham of "tech debt" and "the wiki" fame), which was intended to have business folks write test cases to define how the delivered software would work. And as many people in the Cuke threads pointed out, Cuke fails, too. (As did Fitnesse.)

https://en.wikipedia.org/wiki/FitNesse

Bottom line: There is a ridiculous impedance mismatch between the business side of the house and engineering. Engineering attempts to create a programming language for MBAs is not a solution, but an expression of that mismatch.

Re: COBOL: Thinking about it wrong

#64

Post by sillybov3456 »

benjaminpv wrote: post #13

COBOL was actually in the CS curriculum for my university, a fact that several of my friends brought up when the 'COVID is prompting a real need for COBOL programmers in light of the need to change benefits rules and unemployment!' stories were a regular feature on the nightly news. 'You should do it, man!' Yeah, sure. I'd already suffered through the liquidation of my entire department in 2018, the prospect of the h…

This is all based on a myth though, primarily the myth that "only COBOL" developers are a common thing (people believe this for COBOL even though it's never really been a thing for other languages, wasn't even ever really a thing on mainframes, increasingly they are majority Java).

What I'm getting at is that you aren't going to find a ton of jobs where you are working on COBOL but somehow avoiding Java when the two are connected at the hip on the platforms they are used on.

Re: COBOL: Thinking about it wrong

#65

Post by sillybov3456 »

W-Stool wrote: post #6

People that have not been exposed to legacy industries (banking, insurance, etc) would simply not believe how many of these large/huge companies run the majority of their business on an IBM mainframe running COBOL code. I've seen it firsthand and I didn't believe it. For them, it just works.

Its peak hacker news to come up with a term like "legacy industry".

Re: COBOL: Thinking about it wrong

#66

Post by ipaddr »

BlandDuck wrote: post #36

I have seen the COBOL issue come up a number of times, and I just don't get it. Am I thinking about this wrong? COBOL seems to be a straightforward language by modern standards. Any programmer with experience with imperative languages should be able to pick it up. Learning the language itself cannot be a real barrier. The barrier seems to be the enormous amount of legacy code that has to be digested and understood. B…

Your experiences aren't as straightforward as moving from perl to php but sure anyone can pick it up but it is a journey. I remember finally getting jcl language clicking for me and feeling like I accomplished something.

Re: COBOL: Thinking about it wrong

#67

Post by SoftTalker »

poulsbohemian wrote: post #62
SoftTalker wrote: post #59

Earlier quoted context omitted.

COBOL the language is pretty simple, you’re right. I learned it in a few weeks in my first job out of college in the early 1990s. Even today, you can grab Gnu COBOL and learn the language. What takes longer is understanding the whole architecture of mainframe software. JCL, CICS, etc. It’s quite foreign to anything you learned about programming for Unix. And there really aren’t any free or open-source resources to le…

>What takes longer is understanding the whole architecture of mainframe software. JCL, CICS, etc. It’s quite foreign to anything you learned about programming for Unix. And there really aren’t any free or open-source resources to learn it, as far as I know. This could be what you mean, but isn't the problem here one of access? I know just enough about JCL, CICS, etc to be dangerous, and never found any of the mainfra…

Yeah it was over 30 years ago. I’m sure with more experience it might have been easier conceptually. I didn’t have any trouble with COBOL but found the whole mainframe environment to be rigid, crusty, and difficult to understand and use compared to the Unix systems I had used in school.

Re: COBOL: Thinking about it wrong

#68

Post by markphip »

BlandDuck wrote: post #36

I have seen the COBOL issue come up a number of times, and I just don't get it. Am I thinking about this wrong? COBOL seems to be a straightforward language by modern standards. Any programmer with experience with imperative languages should be able to pick it up. Learning the language itself cannot be a real barrier. The barrier seems to be the enormous amount of legacy code that has to be digested and understood. B…

Some other good points have been raised about what makes it complex, I will add another.

I never learned Cobol, but I learned programming in the 90's on the AS/400 where Cobol and RPG were the primary 2 languages. I obviously used RPG. They are both easy to learn and powerful for what they were meant for but they are also commonly used to create massively monolithic programs where massive transaction programs are all written in a single file or with a lot of "copybooks". It makes it a lot harder to reason in your head what is going on as well as the side effects. Things like unit tests are just non-existent so it is just difficult to make changes because of the potential consequences. Especially when these monoliths are handling such important data.

We wrote our RPG in a very API driven fashion where we avoided monoliths. I think you pay a small performance penalty for this but it always made our code easier to maintain.

Of course it also takes a very long time to compile these programs so the Edit/Compile/Debug cycle is not fun or productive.

Re: COBOL: Thinking about it wrong

#69

Post by jmclnx »

> That last application garnered plenty of attention during the pandemic when state UI systems running COBOL were unable to handle the unprecedented flood of new applicants

COBOL was not the issue, it was all the "webizied" front end developed for people to use via a browser that had the issues. A couple of articles came out with details that, as usual, the mainstream press ignored.

Re: COBOL: Thinking about it wrong

#70

Post by II2II »

moomin wrote: post #7

I'm pretty sure I'm thinking about it right. How much COBOL code can run on a regular Ubuntu machine? What's the package manager for OSS packages? What test frameworks are in common use? You know you're in trouble when "There's a syntax file for VSCode." is the height of your modernity.

That would be like claiming PowerShell is irrelevant because it is not on the typical Ubuntu machine. While it is irrelevant to the typical Ubuntu user, the world is a diverse place and computing is no exception.

That being said, I feel that the article made very weak arguments so I don't blame anyone for perpetuating the stereotypes. These are things such as mentioning which industries it is used in, but not being specific as to how it is used (which is important since COBOL seems to be a domain specific language) and relying upon authority when claiming it is modern.

Post reply on HN