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

81–90 of 139 posts

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

#81

Post by goatlover »

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…

> one of the biggest productivity improvements in the history of programming, comparable to the introduction of Java and VM-based programs in the 1990s.

If languages like Smalltalk, APL and Lisp aren't counted, then sure, Java was big productivity boost in the history of programming.

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

#82

Post by overcast »

cm2187 wrote: post #37
dzdt wrote: post #35

Earlier quoted context omitted.

This. Suppose you want to rewrite. Your task is to create a new, cleanly written program in a new language that produces the same output as the old, slightly messy COBOL. It must work identically for all appropriate inputs. There is no documemtation of the code and insufficient documentation of what combinations of inputs must be supported. No one understands the business logic fully. And there are 500,000 lines of c…

Where I work I heard the IT dept literally had to pull developers from retirement to make a change to the payment systems. Sadly pulling people from retirement is an option that the company will not have forever. At one point there will be no other choice but a complete rewrite.

Listen, you make Cobol programming highly lucrative, and there will be plenty of people coming to do it.

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

#83

Post by 52-6F-62 »

cm2187 wrote: post #37
dzdt wrote: post #35

Earlier quoted context omitted.

This. Suppose you want to rewrite. Your task is to create a new, cleanly written program in a new language that produces the same output as the old, slightly messy COBOL. It must work identically for all appropriate inputs. There is no documemtation of the code and insufficient documentation of what combinations of inputs must be supported. No one understands the business logic fully. And there are 500,000 lines of c…

Where I work I heard the IT dept literally had to pull developers from retirement to make a change to the payment systems. Sadly pulling people from retirement is an option that the company will not have forever. At one point there will be no other choice but a complete rewrite.

This happened to my grandmother even in the early 90's because of her knowledge and experience with COBOL and Fortran. Also because she knew the software. This was for Shell Oil, I think.

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

#85

Post by corpMaverick »

wiz21c wrote: 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…

> 2/ COBOL forces you to mix concerns : DB access, file I/O, business logic. This is sometimes useful to get a complete picture of what’s going on in a program. In Java, you have to wander through your DAO, data model, business logic, etc. which are spread everywhere.

Java doesn't force you. You can structure your code in many ways. In particular nothing is forcing you to have objects like Customer, Order, Invoice, etc. It is just the way OOP has been traditionally taught. Specifically in enterprise applications where a lot of the logic revolves around the data tables makes sense to have objects like CustomerTable, OrderTable, InvoiceTable and have all the related code encapsulated. See https://martinfowler.com/eaaCatalog/tableDataGateway.html https://martinfowler.com/eaaCatalog/transactionScript.html

All your points make a lot of sense. But it is not an essential part of the language. It is more about the culture prevalent with people using the language. But your point is well taken. Maybe we can learn from other programming cultures.

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

#86

Post by zwerdlds »

Not having worked with COBOL in about 10 years, the critiques I have of it (from memory) are virtually identical to some modern languages I still have to work with daily.

It's - Too structured. - Poor tooling. - Whitespace sensitivity. - No first-class functions.

But the article is right - if these same standards were applied to today's languages, things would be a lot louder.

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

#87

Post by Chathamization »

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…

Fortran's older and Lisp is as old (it can be argued about whether COBOL or Lisp are older). Fortran and Lisp seem to have held up much better. ALGOL is another contemporary, and arguably the one that has the biggest impact on popular languages.

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

#88

Post by wvenable »

maxharris wrote: post #2

Oh my God. I wasted a year of my life on a COBOL project. It is easily the worst language I have ever used. There is a reason that COBOL is a linguistic dead-end! Functions? Sensible limited variable scope? A decent approach to handling whitespace so that complex, nested branches make sense? COBOL doesn't even have these basics. Want to declare a variable? You're gonna have to type weird stuff like this: `07 GreatVar…

I spent a little less time that you doing COBOL and I've never been less productive as a programmer in my life. The language is terrible and the ecosystem is worse. What should take a week to code and deploy took months.

To answer the topic, I've tried COBOL and I hate it. It doesn't deserve respect except in a historical context.

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

#89

Post by yourapostasy »

fork1 wrote: post #53
yourapostasy wrote: post #49

Earlier quoted context omitted.

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 m…

How does your sales team address your customers' concerns that they are trading one vendor lock-in (IBM) with another (your company's)?

From seeing how the risk is assessed in some of my customers, the kind of emulation approach you described (I've seen one for the old HP 3000, and it worked great) sells easily when the legacy vendor is so sclerotic and rapacious that the customer's management is practically pushed out of the relationship, and the economics don't have to completely pencil out to close the sale.

The customer is tied down to a smaller (usually) vendor's emulation, and trust the fidelity of that emulation over time, and furthermore, over new versions. The customer must maintain a skill inventory that isn't "current" (though some people might consider that a plus).

I can think of a couple ways to address those sales objections (lock-in isn't real: can always switch back to legacy vendor if all else fails, no need to revamp staff with crucial business/domain knowledge, etc.). But I'd be really interested in how your sales team deflects them, because I anticipate this legacy software issue will only get worse in our industry over time, and not just on mainframes. I'd like to try to figure out how to bring down the friction of such sales in the future.

Thanks for your feedback, really appreciated.

Post reply on HN