3 ms·

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. Wh

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.

danielmarkbruce 4y ago
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.
- derefr 4y ago
  > 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 :)
  - danielmarkbruce 4y ago
    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-microfocus-amc-es/doc/micro-focus-enterprise-server-on-the-aws-cloud.pdf 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.
KTSnowy 4y ago
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.
- qbasic_forever 4y ago
  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!
  - KTSnowy 4y ago
    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.
- _yb2s 4y ago
  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.
  - gps0 4y ago
    If only there was a proper tutorial/course for it... Maybe there is? Can you link any?
    - 4y ago
kmac_ 4y ago
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.
shortlived 4y ago
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.

danielmarkbruce 4y ago

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.

derefr 4y ago
> 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 :)
- danielmarkbruce 4y ago
  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-microfocus-amc-es/doc/micro-focus-enterprise-server-on-the-aws-cloud.pdf 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.

KTSnowy 4y ago

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.

qbasic_forever 4y ago
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!
- KTSnowy 4y ago
  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.
_yb2s 4y ago
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.
- gps0 4y ago
  If only there was a proper tutorial/course for it... Maybe there is? Can you link any?
  - 4y ago

kmac_ 4y ago

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.

shortlived 4y ago

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.