Hacker News Reader

Comment by KTSnowy | Hacker News Reader

Given the amount of proprietary and paid-to-use COBOL compilers which run on .NET and the JVM, I would say that you're not correct. It does in fact run on .NET already.

The fact that there is a COBOL 2022 standard (yes, it's still being maintained) should have given enough of a clue that COBOL doesn't run only on legacy mainframes and tape drives anymore.

Sure, there are still companies using COBOL 85, but that's not the fault of the language. You wouldn't blame Java itself if companies used a version from the 90s intead of a newer and better version.

I find it quite absurd when people hate on COBOL based on its version from the 80s, while ignoring it's newer standards.

View on HN

In a similar light, I recently spent some time working with modern Fortran, and was amazed to find it a modern, efficient, and intuitive language for scientific computing that in many ways makes Python look archaic. Not at all what I was expecting given its age And reputation.

If only there was a proper tutorial/course for it... Maybe there is? Can you link any?

There are a lot of good tutorials you can find with a search, but I don't remember any specific ones right now.

AFAIU, Fortran acquired most of its bad reputation in the 60s and 70s. I think it was much more widespread than it is today. Then, as time went on, Fortran moved to the niche it was intended for originally (scientific computation) and was replaced by other languages for general purpose programming. Fortran continued to evolve, but few people got to see that, unless they cared to look. The rest of the world remembered the FORTRAN of old.

Additionally, it should be noted that mainframe IBM COBOL has also continued to be updated and extended, to the extent that it has native support for JSON serialization/deserialization for building web services.

There is an enormous amount of new COBOL being written even for mainframes.

There is almost certainly a large market for COBOL on .NET if it managed to replicate some of the functionality IBM added on top of the standard.

A better term for COBOL (and mainframes for that matter) would be niche, not legacy. It's the best language for a very particular subset of business problems, and there hasn't really been much attempt to replicate that functionality by newer languages, and so COBOL remains in use. There simply is not much overlap between the folks coming out of school interested in language design/theory and those that are aware of COBOLs continued dominance in certain types of business.

It's also ruthlessly efficient compared to something like Java or .NET, and even beats out C by a wide margin in certain scenarios. That isn't as important if your not laying mainframe licensing fees, but it is a common headache that makes migration to some of the current virtualization based modernization platforms a headache.

Eh. I worked on IBM's COBOL compiler for four years or so, and I think you're overselling COBOL. COBOL is the best language for extending the functionality of critical legacy systems already written in COBOL. I have a soft spot for the language, in the same way you might for a puppy that is big-hearted but ultimately not very bright, but I can't imagine a greenfield project where COBOL is the right implementation choice. (Idiomatic COBOL does end up being surprisingly fast, mostly because the idioms were established in the 60s where things like "dynamic memory allocation" and "a call stack" were too expensive.)

The market for COBOL on .NET is limited by the fact that existing COBOL code is usually tightly integrated with the rest of the mainframe ecosystem (CICS, etc). The average COBOL shop has a low appetite for significant change. Even just recompiling the codebase with a newer version of the IBM compiler was often a big lift. (IIRC, when I left, COBOL 6.1 was generating code that was nearly twice as fast as COBOL 4.2 for CPU-bound code, although admittedly a lot of real-world COBOL isn't CPU-bound. It was still difficult to get people to migrate.) Anybody who wasn't change-averse and tied to the mainframe probably stopped being a COBOL shop years ago.

Edit to add: None of this is to say that Otterkit isn't a cool project! I just don't expect it to sweep through the world of banking.

I'm not hating on COBOL... I asked who the customers are for making this a product. I guess they're out there, good luck!

I understand, but this is an open source compiler. It's meant to be used by anyone who is interested in the language, or maybe by companies that wish to replace their quite expensive compiler licensing fees with an open source solution.

I don't see this as a product that needs to attract customers. It's free and open source, anyone can use it.

Reply on news.ycombinator.com