Live data from Hacker News

Don't hate COBOL until you've tried it

opensource.com

71–80 of 139 posts

Re: Don't hate COBOL until you've tried it

#71
There was this really great COBOL programmer back in the 1990's who was making piles of money hand over fist, but was overworked and getting really tired of working on Y2K fixes, and becoming extremely worried that civilization was going to collapse due to Y2K bugs. She never wanted to look at another line of COBOL ever again, she was so sick of it.

So she signed up with Alcor, and had herself cryonically frozen in 1999, leaving behind explicit instructions that she was to be revived after civilization had finally put itself back together again.

Finally she woke up, in a clean futuristic hospital room, surrounded by inscrutable machines that go "ping" and strangely dressed doctors with funny accents and weird hairdoos.

She was so happy to be alive that she proclaimed "Thank you so much for bringing me back to life! I am eternally grateful, and in your debt! Is there anything I can do to repay you? And by the way, what year is it?"

One of the doctors smiled at her and said, "Yes, actually. It's the year 9999, and the records indicate that you're a COBOL programmer..."

Re: Don't hate COBOL until you've tried it

#72

Earlier quoted context omitted.

> because you could control the data layouts very precisely You can do that in assembly too

Ah. I’ve been downvoted... Guess I should’ve been more clear. I was referencing how the OP said COBOL was easier for data layouts. So, not really knowing COBOL, I was asking why. Poor wording.

The feature we’re talking about here is an easy to use version of doing memory layouts like you’d do with C structs and unions. And combined in with that is automatic number formatting. And all of it uses a clean concise layout that’s self documenting.

Re: Don't hate COBOL until you've tried it

#73

I'm curious about something. Why this: if shipping-method 'FX' move normal-ship-date-yyyymmdd to expected-shipping-date else move nextday-ship-date-yyyymmdd to expected-shipping-date. And not the following? if shipping-method = 'FX' move nextday-ship-date-yyyymmdd to expected-shipping-date else move normal-ship-date-yyyymmdd to expected-shipping-date. The latter seems clearer to me, and the line below (regarding the…

Probably taste: normal case first, special case last, regardless of what the respective comparison clauses look like.

Also efficiency, you want the most often true thing first. Although it is more important in nested if's. Had a colleague write a If else nested 104 levels deep (pre COBOL II so no case structure available). We halved the run time of the program simply by making the four most common conditions the first four.

Re: Don't hate COBOL until you've tried it

#75
post #54
post #9

I think COBOL is not a question of hate vs not hate. To hate something you need to consider it, you need to have requirements. If nobody shares an article like this one nobody is actually THINKING about COBOL. If someone starts a new project COBOL is not on the list of possible programming languages to implement it in. If you want to make it more popular don't fight hate, fight ignorance. But to be honest I'm one of…

> If you want to make it more popular I don't think that's a desirable goal. COBOL is not a very good programming language: it's verbose, clunky, cumbersome and outdated. It still exists because of tons of legacy systems and (understandably) conservative businesses like banks. But if you start a new project, please DON'T consider COBOL. To be honest, even my recommendation is irrelevant: you wouldn't start a new COBO…

Well... if I was starting a new project that had to run on an MVS mainframe, I probably would in fact consider COBOL. But I'm relatively happy that I probably won't be in that position.

Re: Don't hate COBOL until you've tried it

#76
post #16

I have regualr talks with people who were using COBOL a while ago. There are things were cobol is good : 1/ COBOL run in closed environments. This allows these to be rock solid. (no such thing as a dependency nightmare). You don’t have such a thing as different version of Java on your testing and production environment. 2/ COBOL forces you to mix concerns : DB access, file I/O, business logic. This is sometimes usefu…

COBOL supports "includes" (called copybooks I think) which is poor-man's re-use but at least lets you avoid defining the same common record formats and subroutines individually in every program that needs them.

Re: Don't hate COBOL until you've tried it

#77
post #8

It's surprisingly well adapted to web development too http://www.coboloncogs.org/

If you have an existing COBOL app you can convert it to a web app and develop using a simpler syntax with more features through SystemZ from Zortec Intl. I've worked with them personally and they were super-duper. COBOL isn't so bad when you use a modern variant that purposefully deals with many of the complaints surrounding it.

> COBOL isn't so bad when you use a modern variant that purposefully deals with many of the complaints surrounding it.

Isn't that basically how JavaScript took over the server space via node.js?

Re: Don't hate COBOL until you've tried it

#78
post #54

Earlier quoted context omitted.

> If you want to make it more popular I don't think that's a desirable goal. COBOL is not a very good programming language: it's verbose, clunky, cumbersome and outdated. It still exists because of tons of legacy systems and (understandably) conservative businesses like banks. But if you start a new project, please DON'T consider COBOL. To be honest, even my recommendation is irrelevant: you wouldn't start a new COBO…

Well... if I was starting a new project that had to run on an MVS mainframe, I probably would in fact consider COBOL. But I'm relatively happy that I probably won't be in that position.

Agreed on all counts. Do note that "making the language more popular" doesn't factor into this: if you need to start a project on an MVS mainframe, you already know about COBOL!

Re: Don't hate COBOL until you've tried it

#79
I worked for one of those companies using COBOL. This strikes me: > Once I discovered what the problem was, the fix was easy: I deleted one character of white space from the beginning of line 19, which put the period at column 72. Although I'd never encountered it before, this was such a common bug that many mainframe COBOL programmers would tape a piece of thread between columns 72 and 73 on their terminals. Why would you want a compiler/language that allows you to shoot yourself in the foot for 1 misplaced character in the source file, without raising an error instead of blindly executing the code? Like you said, it can change completely the logic of the code so it could be disastrous and go unseen, especially in business transactions? I know things changed recently. But I would be very surprised if the company I worked updated their COBOL version.

Re: Don't hate COBOL until you've tried it

#80
I've tried it, so I can say authoritatively: no thank you. Yes, Admiral Hopper should be revered for her work but we have successors now that are superior.

I'm happy not to work with JCL, COBOL, EBCDIC, and mainframes in general. I realize just how much awesomeness in my OSs that I was taking for granted.

Post reply on HN