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

Don't hate COBOL until you've tried it

opensource.com

Post reply on HN
Print view View original

51–60 of 139 posts

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

#51

Post by cholantesh »

colejohnson66 wrote: post #45
hodgesrm wrote: post #23

I have not used COBOL for 30 years but the language deserves respect. The transition from assembler to COBOL was one of the biggest productivity improvements in the history of programming, comparable to the introduction of Java and VM-based programs in the 1990s. COBOL is still pretty efficient for tasks like scanning data on magnetic tapes--not that most of us do that any more. In fact it was pretty good for any pro…

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

But it is undoubtedly more efficient to do so in COBOL.

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

#52

Post by fork1 »

pjmlp wrote: post #48
fork1 wrote: post #47

Earlier quoted context omitted.

There are alternatives, but i'm biased. See my other comment. One of the biggest hurdle we have is that the clients dont usually have many tests in place. Testing and validating a full batch night for example (ie 6 hours of intense batch work) is quite complicated.

I see, it is a valid alternative. What do you think about the .NET and JVM Cobol compilers? They seem to be a way to move that code into new systems with no rewrites as well.

Well, i know of at least one client that still has the binaries but not the sources of the cobol.

But for the generic case, the mainframe is quite an integrated system, and big clients tend to use a lot of the features at the same time. Even if you can produce an executable or a library, but you ll still need a transaction manager (CICS/IMS-TM), a database (DB2/IMS), MQ, RACF, Datasets, GDG, REXX/JCL, etc. You need the whole ecosystem. And all the binaries will expect a DB2, or a MQ listening on the other side, with near-perfect emulation (return codes, db behaviour such as EBCDIC sorting, etc). Just compiling wont help you much unless you have a very basic use of mostly JCL and batches.

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

#53

Post by fork1 »

yourapostasy wrote: post #49
fork1 wrote: post #42

Earlier quoted context omitted.

Cobol programmers are starting to get few nowadays, and finding people that actually want to be trained in it is not that easy. Plus you dont just need programmers, but z/OS engineers, DB2 DBAs, MQ specialists, etc. And that's before you even start talking about the nice cheque you're writing for IBM every month. It does add up.

Most if not all such managers (I always look for explanations in these cases that are not ascribed to an abstract business entity, but to individual people) have no stomach for porting. A typical manager's tenure over an organization that might have the scope to perform the port is shorter than the porting project itself. No manager wants to have such a large, expensive, risky project on their accomplishments list as…

As i've made clear in my other posts in this thread, i dont believe in rewrites. I've seen lots of very painful ones though, and never quite finished, nor iso-functional. However, there are other ways to unplug the mainframe.

I would disagree with the assessment that management is too dysfunctional, it depends. But if they all were like you described, i would be out of work. And it just happens that we turned off a mainframe just 2 weeks ago.

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

#54

Post by the_af »

erikb wrote: 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 COBOL project just as you wouldn't start a new GW Basic project -- it'd be unnatural.

Disclaimer: worked with COBOL for a bank. It wasn't pretty.

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

#55

Post by lithos »

colejohnson66 wrote: post #45
hodgesrm wrote: post #23

I have not used COBOL for 30 years but the language deserves respect. The transition from assembler to COBOL was one of the biggest productivity improvements in the history of programming, comparable to the introduction of Java and VM-based programs in the 1990s. COBOL is still pretty efficient for tasks like scanning data on magnetic tapes--not that most of us do that any more. In fact it was pretty good for any pro…

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

COBOL is well described as the language for regular expressions over tables.

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

#57

Post by erikb »

the_af wrote: post #54
erikb wrote: 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…

It was just an assumption, based on someone writing an article called "Don't hate COBOL until you've tried it". As said, I personally wouldn't even consider it, so there is zero chance to hate it as well.

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

#58

Post by cafard »

cm2187 wrote: post #33
skissane wrote: post #30

Earlier quoted context omitted.

> But how complex can these programs be? Surely anything written before 1992-ish can’t involve that much code just because of the limitation of the machines they were designed to run on An ex-colleague used to work for a major US insurance company, and this is what he told me: They had a bunch of products, and due to the state-by-state nature of US insurance regulation, they had a slightly different version of each p…

That's interesting. It's a form of adverse selection. The least maintainable and readable languages end up sticking around the longest whereas the clear, concise and readable languages are likely to be replaced regularly with the shiny new thing...

COBOL is readable, in the way that Soviet-era novels were: it all makes sense, it's just tedious. COBOL is as we have seen maintained, so how is it not maintainable? I agree with you that it is not concise.

[Edit: changed period to question mark]

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

#60

Post by dontlikeitupem »

hodgesrm wrote: post #23

I have not used COBOL for 30 years but the language deserves respect. The transition from assembler to COBOL was one of the biggest productivity improvements in the history of programming, comparable to the introduction of Java and VM-based programs in the 1990s. COBOL is still pretty efficient for tasks like scanning data on magnetic tapes--not that most of us do that any more. In fact it was pretty good for any pro…

The best thing about COBOL is the distinct lack of hipster coders or frameworks. I worked on various COBOL code bases over the years, and they were always approachable, if a little long-winded. My cheques still process via COBOL code a friend's grandmother wrote and still runs on emulated Unisys hardware.
Post reply on HN