Hacker News Reader

Comment by qbasic_forever | Hacker News Reader

Who do you expect to use this? As I understand it most COBOL use is on legacy mainframes that definitely aren't going to also be running .NET anytime soon. When a company is hiring a COBOL programmer they aren't hiring someone to just sling code--anyone can learn the language--they're hiring someone who can parachute into decades old legacy systems with zero documentation, archaic and non-existent media (tape drives), wildly out of date systems and tools, etc. and instantly be productive. Modern interop with this world is curious.

View on HN

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.

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.

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.

Modernization projects move COBOL code running on mainframes to COBOL code running on the jvm or .net, on x86 machines, using all kinds of libraries emulating services provided by the mainframe OS/environment. It's pretty amazing really.

> using all kinds of libraries emulating services provided by the mainframe OS/environment

Can you give an example of "services provided by the mainframe OS/environment" that could be practically/scalably emulated on a microcomputer architecture using library shims? Because those honestly sound like the sorts of things one might want to use even for non-legacy purposes :)

A database. To be clear though, it's usually a library plus a service. It could be library + sqlite etc though I guess. Look here for example, page 8:

https://aws-quickstart.s3.amazonaws.com/quickstart-microfocu...

It's pretty amazing, big companies make these migrations on important systems. There are 10's (or 100's maybe) of billions of lines of COBOL still being deployed and companies move them into a cloud (ie aws etc, x86 + cloud services) environment for various purposes.

I met an old colleague and during a chit-chat he said that he diverted into COBOL world. It turned out that the community is quite large, new versions are rolled out frequently and there's a demand for new devs. Looks like there's plenty of areas in our industry that are not covered daily on HN, but they exist and thrive.

Mainframes aren’t legacy, they’re just different and not well talked about that much in public. They have a full Unix subsystem with modern ports and lots of integration via VS code extensions.

Reply on news.ycombinator.com