Hacker News Reader

Comment by Roboprog | Hacker News Reader

I got a laugh out of the ad at the bottom of the page: “convert COBOL to Java”.

I mean, it’s the first thing that went through my head when I saw the article, but...

We got off of that 60 year old language, and are no longer beholden to IBM!

... to be on a 30 year old language (that few outside of management love), and owe our souls to Oracle.

Yeah, balancing stability and ease of use is hard. The post-Java landscape is pretty fragmented with many more developer friendly options, but it’s hard to know what will still be well supported in 20 years. I like JavaScript - which is also as old as Java, but seems to have aged better - but I understand that it scares the hell out of many developers.

So what do we replace COBOL with?

View on HN

> So what do we replace COBOL with?

Why replace it at all? Why not build up GnuCOBOL, and evolve the needed IDEs, deployment infra, and mainframe functionality replacements around it, so we can continue to use old, functioning code in new ways?

Insisting on rewriting the code is insistence on simply never completing the project at all.

A lot of COBOL software is running on IBM mainframes under z/OS. In that case, it isn't just COBOL, it is all the middleware and OS components the COBOL interacts with – CICS, IMS, DB2, VSAM, JCL, DFSORT, etc, etc, etc. Duplicating all of that functionality is an infeasible task. Duplicating a big enough subset that you can successfully port a real world mainframe app is achievable, and a number of commercial offerings exist which do that – e.g. Oracle Tuxedo Application Runtimes for CICS/IMS/Batch, Tmaxsoft OpenFrame, UniKix, etc. However, building such a solution is a huge amount of work requiring a rare skillset, and I doubt the open source community has the ability/resources/motivation to replicate that work.

I hear that. I worked at a place in the early 90s that had a product to port System/36 based RPG II code onto newer platforms. It kept 4 of us pretty busy, and RPG is just a small language doing flat files on a mini with a simple scripting language (OCL = operation control language) and job queue system.

Later we took on the AS/400 version, but I left before that product went live.

I can’t imagine how much IBM’s mainframe system has sprawled out over the last quarter of a century.

It would be interesting to see all the places that have this problem hire a team of open source people to tackle this with the intention of solving it for all instead of just for some. A collective solution contributing to the commons, I think it could work.

Serious question: unless some company is keen on getting commercial support for Java from Oracle and using Oracle’s tooling (in which case, you do you, good luck and Godspeed), what is the difference between using Java with an open source implementation of JDK and using any other language which is built using open source compilation/runtime/build tools? Remember too that OpenJDK is the reference compiler for Java - anything fancy that Oracle offers is a bonus, the language doesn’t support it by default.

FWIW I work nowhere near management and I love Java, it’s easy to use and you can do pretty much anything you want with it. I say this as a middleware developer - there’s really no other platform than the JVM that I would like to use, and while I could spend months learning Kotlin or Scala or Clojure I could also just take the easy, lazy road and use Java. It’s not cutting edge, but I don’t need cutting edge. I need stability and as many actively developed libraries as I can to make my job as easy as possible. YMMV, but it’s not really fair to paint Java as a dinosaur that is loathed by non-management types, that’s just not true.

Aside: I have only experienced COBOL code second hand, though I was briefly threatened with it back in ‘88.

I do appreciate how it seems oddly more compact than most “Enterprise!” java code - e.g. copy books vs beans. How many times we gotta name the damn field to use it?

Reply on news.ycombinator.com