Hacker News Reader

Comment by SmellyGeekBoy | Hacker News Reader

Speaking as someone who occasionally gets roped into supporting a COBOL application at a large financial institution, I genuinely don't get the "we must replace it because it's old!" mentality. If it's still the best tool for the job then why move away? Just train people up and build tools to work with it on modern systems, just like Micro Focus and COBOL Cowboys (both mentioned in the OP) are already doing. As an added bonus, you can make a lot a money in the process too.

"The guy who wrote it left and nobody knows what it does" is a poor excuse with a self-documenting language like COBOL. How much sense do you think your tangled mess of Java will make in 50 years?

View on HN

>"we must replace it because it's old!"

My guess as to where that came from:

1. Tech companies stay relevant by reinventing new markets via new languages / frameworks. 2. New programmers can side step the "rookie" condition by adopting a new language thus leveling the playing field for that language / framework (i.e. everyone is a rookie). Plus whatever is new is hot, and everyone wants to know what's hot. 3. Because of this, few are interested in old languages. I was in college in the 1990s and COBOL was pretty much out as far as anything anyone wanted to learn. It was all Windows.

So based on 1-3, the reason "we must replace it because it's old!" mentality is out of necessity. The older the system / language, the harder it will be to find people to work on it. This has inherent risk. Of course these banking systems have decades of business logic, acquisition logic, and government regulations built into them, rewriting it has it's own massive risk.

While I generally agree with the "if it ain't broke" sentiment, you have to perform some pretty wild mental gymnastics to end up calling COBOL the "best tool for the job".

Adoption and ease of learning should always be considered when selecting a tech stack for a solution. COBOL's semantics are so foreign to modern programming languages that it makes the language pretty inaccessible.

Also, COBOL's strength is in the generation of reports, but in the end, it's no more expressive for that purpose than any general-purpose programming language coupled with a nice report generation library.

>While I generally agree with the "if it ain't broke" sentiment, you have to perform some pretty wild mental gymnastics to end up calling COBOL the "best tool for the job".

Do you? Lack of programmers, aside, it was created and evolved exactly for the kinds of jobs its used in.

It is something of a DSL, as the name suggests (Common Business Oriented Language).

I would also disagree with GP that COBOL's semantics are really very foreign. Variable declarations, assignments, expressions, loops, conditionals, etc. are not that different from other imperative languages. More verbose, certainly, but not foreign.

JCL on the other hand....

If it's similar to other imperative languages, what makes it a DSL? What is the domain of "business"?

It's similar to other imprative languages in some constructs, it's very business application focused in others -- e.g. built-in support for forms, for monetary calculations and such.

I think the real problem is that it needs to be maintained and nobody wants to do it. So… just start over in a more fashionable language, I guess.

Something I wonder about all the time is why software has to be so fragile. We always put so much work into maintaining things downstream because things break upstream so often it's frustrating.

Reply on news.ycombinator.com