8 ms·

What if we could transpile COBOL into Elixir

58 points by cgarvis 5y ago

philipswood 5y ago
Please no... I've been unfortunate enough to witness first hand what +-5,0000,000 lines of Natural Adabas code transpiled to +-15,000,000 lines of Java code looks like, and it was not pretty.
- chris_st 5y ago
  This. Friend of mine worked at a company that did COBOL to Java compilation, with the intent of producing "maintainable" code, and he reported (after several years of work) that this just wasn't possible (for them).
- chess_buster 5y ago
  I would like to know more… 8-)
  - philipswood 5y ago
    This is from hearsay, since I was only there a few weeks before getting out, so I only spent some time on the floor and looked at the code for a bit: It was a municipal management system that grew over time (decades). At some stage a government standards body raised the legacy risk inherent in the Natural Adabas codebase. Some (pretty impressive) 3rd party tool was used to transpile the codebase to a more "modern Java web application architecture". The code wasn't idiomatic Java and used some extension libraries to supply missing capabilities. For example I don't recall ever seeing any other Java system that uses continuations. I spent an entire day tracing one field from the front-end to the database. I documented the components, flows, logic and db structures and then asked one of the team leads to verify if I got it right. She confirmed that I did. I then asked what the code on question actually does, functionally. She replied something to the effect of "Good heavens, I don't know either - you'll need to speak to one of the functional guys and then spend some time with the Natural code from before the transpilation". She needed about 6 months to get a new Java dev to a level where they could do minor feature requests or bug fixes. Understandably her ability to retain developers was quite low - they tended to leave quickly after spending time with the system. Business didn't seem to get why the velocity for new features was so slow. They didn't have an architect, documentation was fragmentary. Previous modernisation initiatives had already become obsolete as well: IIRC the App server was Glassfish and front-end (web) components were using some JBoss widget library that was already deprecated at the time. Like I said, I left quickly.
- HideousKojima 5y ago
  I've had to port some old Visual Basic WinForms apps to C#, only a few hundred lines of code for each app, and even that was a huge pain in the butt. Transpiling anything of significant size and complexity will require a metric ton of cleanup and refactoring just to make sure it all works right and can be reasonably maintained by other developers.
sharklazer 5y ago
Then you could transpile COBOL into Elixir...
WJW 5y ago
You can transpile anything to anything, but computers will not be able to rewrite the code to match idiomatic style in the new language. Rather, (taking the example from the article) you get COBOL style in Elixir syntax and everyone is unhappy. Much better options are to maintain a COBOL team that continuously updates the program during its lifetime so that knowledge of how it works is never lost, or (if that is no longer possible) do periodic rewrites every two decades or so. If your first response to this is "but that would cost a fortune!", you are completely correct. The biggest illusion in software is that a "complete" program is now "done" and will need no more investment. Software is a machine for producing information, fundamentally not much different from a lathe or a textile loom. If your company depends on a piece of software to continue existing, it is now de facto a software company. Many institutions have not yet realized this and will run into existential problems within a few decades.
- scns 5y ago
  Several Clojure libraries would like to have a word with you ;) Disclaimer: Neither a fanboi nor user, just read that potential users thought those libs were abandoned, since they havent been updated in years.
restlessbytes 5y ago
> What if we could transpile COBOL into Elixir You've then successfully ported your code base from one language for which it's really difficult to find programmers to another language for which it's really difficult to to find programmers.
- carlmr 5y ago
  I guess your comment was in jest, but I can find plenty of developers for elixir that are willing and able to learn it in a month if I want to.
  - rad_gruchalski 5y ago
    Do you think they’d be happy to maintain a transpiled COBOL code?
    - carlmr 5y ago
      No, of course not, I was just getting at this specific point that there are few COBOL and Elixir developers. Which, while true, has little to do with the talent pool you can draw from.
      - rad_gruchalski 5y ago
        Makes sense. I’ve done some fair share of Erlang myself some years ago.
  - LeonenTheDK 5y ago
    My company (I'm not the hiring manager, just in the know) has been struggling to find any kind of programmer who either knows Elixir, or who is willing to learn. I'd love to help them along because the workload is getting rough. Are there any tips you can share about finding them? Where do you post ads, what's the process like, remote or in person? Anything would help. Thank you!
    - 5y ago
tyingq 5y ago
You will have solved the easiest part. Now get started on replicating JCL, VSAM, CICS, IMS, RACF, and the rest of the ecosystem that COBOL code depends on :)
- acdha 5y ago
  Back in the late 90s I had the bright idea of shipping our COBOL runtime as a browser plugin. This worked relatively well for a fraction of our customers since we had a transparent remote ISAM & RPC system the plugin could use (the idea being that the browser plugin meant you only had to update your Windows desktop clients with new versions of the runtime; they'd get the latest app on load) but the rest had a huge thicket of system-level dependencies which made that hard to consider, and that was for customers who'd already been able to migrate off of mini/mainframe systems to Unix. At this point in time, the mistake is to hear “COBOL” and think about a programming language rather than environments where they've struggled to manage technical debt and staffing issues for decades. It's not that COBOL developers can't produce good code but rather than places which can modernize effectively did so 3+ decades ago. If some place makes the news now because of a COBOL-based system, COBOL is a symptom of a management failure.
  - tyingq 5y ago
    Ah, a cobol browser plugin? Cool. And yeah, environments. It's like porting JS to the mainframe, but not providing the POSIX facade to allow it to make files, schedule batch jobs, kill processes, connect to the network, store data in a database, access rights, auth, etc.
    - acdha 5y ago
      Yes – AcuCOBOL had a COBOL development system which was byte-coded like Java (the technical founder had actually overlapped with Gosling in undergrad, I believe) so we already had the capability to copy the compiled program onto most platforms (Most Unix variants, VMS, Win16 and Win32, OS/2, DOS, OS/400, etc.) and launch it with the native runtime. There was also some ability to transparently redirect I/O — you could have any CALL which didn't wasn't in the local compiled code do an RPC call to a remote server, and redirect some or all ISAM operations to either a remote server or (with another license) a SQL database. Once they had that infrastructure, it wasn't a huge amount of work to package the runtime as a plugin which was configured to enable the remote call & I/O options by default. Which is exactly restating your last point: having already done the hard 95% of the work, this part was straightforward.
scns 5y ago
Why should we? When we have this: http://www.coboloncogs.org http://www.coboloncogs.org Sorry, no https availlable.
cdumler 5y ago
There are plenty of ways to port out of COBOL, none will work. I once interviewed for a COBOL position. It was a typical large financial institution. It was a lead position that wanted a migration plan out and then would lead to a team for me. I have a lot of systems integration and information management knowledge. I have worked on planning multi-year projects and migrating out of large systems like this before. The interview went well, and afterwards they showed me around the place and what they were doing. I sat down again in the office with the hiring director, and I enquired about how long he has been with the company and what he has been working on. Turns out he had been hired in five years ago and had already attempted this once before without success. I knew without a doubt why they didn't have success, and it had nothing to do with COBOL. Financial companies are highly risk adverse. COBOL developers know this. COBOL developers know that if the shop isn't COBOL their job is at risk. So, COBOL developers will constantly introduce "what about this risk" issues, which then must be considered in committee; thus, the company is eternally paralyzed. The fact that the director couldn't make it anywhere in five years meant nothing was going to change. As I recall, I checked in a few years later and they were still in the same place. I suspect it might have been a decent place if all I wanted in life was a paycheck. They were nice people.
- goto11 5y ago
  Are these COBOL programs running on obsolete hardware, or are the systems virtualized these days? I suspect the way forward for COBOL is to modernize the development tools around it, rather then rewrite the code itself.
  - rad_gruchalski 5y ago
    Have a look at Micro Focus compiling COBOL to .net and java. They’ve been doing this for minimum 11 years now.
  - rovr138 5y ago
    Obsolete hardware? Mainframes are still a thing.
    - 5y ago
lucozade 5y ago
I feel a need to comment but I can't find a form of words that isn't condescending to the point of rudeness. So this will probably come off as rude... Transpiling, to more or less any language, is the easy bit. By a very, very long way. The hard bit is everything else. I mean, do they really think they're the first people to think about using a transpiler over the last 30/40/50 years? If they had said that they'd used their transpiler on a real production codebase and their transpiled code was now running in production in any volume, I'd be quite impressed. But they didn't say that because it's blatantly obvious from the tone of the article that that will never occur. Now, I don't have any issue with people being ignorant of a subject that they don't understand. That's the norm for most people for most things. But I have to say that this level of naivety doesn't reflect well on their company. They clearly made no effort to understand the problem that they are purporting to solve. Is that really how they function as a company?
Wildgoose 5y ago
The Japanese have a philosophy whereby they will rebuild a shrine every 20 years. The knowledge of what is necessary remains current, and understood. And the shrine continues in its purpose. Perhaps we should consider how we can regularly rewrite different parts of our software ecosystems using new languages and approaches while preserving the essential knowledge and security aspects of what we have already built? The important part isn't the language that the code is written in, it is the full understanding of the problem and thus the solution provided.
- flohofwoe 5y ago
  IMHO a more realistic idea is to treat the COBOL code as the "idea" or "essence" of the shrine which eternally remains the same, and only rebuild the "physical presence" of the shrine, which would be the environment the COBOL code runs in (e.g. modernize the hardware, the operating system, the debugging/development tools and virtual environment (== emulator) the COBOL code runs in, but don't rewrite the COBOL code itself).
  - rowanG077 5y ago
    But then you have solved nothing...
    - flohofwoe 5y ago
      Maybe, but "nothing" is still much better than making things worse (first, a rewrite usually needs to be bug-by-bug compatible, so you have almost no leeway to "improve" the product, second, new code has new bugs that need to be found and fixed, don't underestimate the amount of work that has gone into a 50 years old code base that still does its job).
- ehnto 5y ago
  I don't think new languages and tools are necessary in all circumstances, I imagine part of the process of rebuilding every 20 years is to not forget how to build in the first place. Being around for the frontend engineering revolution taught me what it means for an industry to forget how to build, and have to re-learn many already hard learned lessons. But maybe I'm looking at it wrong, and it was that re-learning process that was the re-building after all? I don't know. All I do know is that you rarely get enough time in software to master your tools before everything changes, and you have to build the same old software requirements in brand new ways.
bencollier49 5y ago
The issue typically isn't just the COBOL itself, but the surrounding architecture. This will take in the nuances of the underlying operating system, system language operations and batch tasks. For example, the COBOL might potentially have been on an ICL VME system. This will undoubtedly have a lot of support code written in things like SCL (System Control Language), and potentially even 68k assembly. There are companies which specialise in migrating COBOL code from legacy environments. This can involve migrating the COBOL code itself to a different variant and rigorously testing it, and then often introducing utilities which replace operating system functionality which was present on the original mainframe. The alternative is to "salami slice" bits of functionality into modern services written afresh, and slowly work towards decommissioning the old setup, but often this has to be done at the same time as a migration to modern hardware, due to the scale of the systems involved and the time taken for these sorts of projects to complete.
- imglorp 5y ago
  Why would there be any 68k assembly floating around in this domain?
forgotpwd16 5y ago
No one running COBOL will use it because those legacy applications "just work". Debugging and making certain the resulted transpiled code does as well will take a monumental effort (read: money). That is why those codebases haven't been ported because, based on similar efforts, transpilers are only partially easier than a manual rewrite. That answering the what if question. The project itself is interesting.
pronoiac 5y ago
I checked my bookmarks, and there have been success stories for porting cobol into other languages. Here's a discussion from 2019, from cobol into Java: https://news.ycombinator.com/item?id=19839563 https://news.ycombinator.com/item?id=19839563 Phase 1: automation of cobol to (ugly) Java Phase 2: make the code more idiomatic for (cleaner) Java Phase 3: move the infrastructure to AWS In the discussion, someone mentioned "There are commercial COBOL compilers available that compile to Java bytecode." Offhand, if someone were still on cobol, I'm not sure if they'd trust the comparatively new Elixir, but I can also see leapfrogging being a thing. (And I know it's based on Erlang, which pre-dates Java.)
vajrabum 5y ago
Anybody who is developing a COBOL compiler should know that there's a test suite for the language. See here (https://www.itl.nist.gov/div897/ctg/cobol_form.htm https://www.itl.nist.gov/div897/ctg/cobol_form.htm) Also, I haven't seen any mention of any of the bits of the COBOL ecosystem here? No DB2, IDMS, IMS DB/DC, VSAM, CICS, REXX, JCL? These are a big part of why COBOL applications are sticky.
tjalfi 5y ago
This reminded me of the old lisp2cobol[0] joke script. [0] https://stuff.mit.edu/afs/sipb.mit.edu/project/lisp2cobol/l2c https://stuff.mit.edu/afs/sipb.mit.edu/project/lisp2cobol/l2...
rhabarba 5y ago
COBOL code is surprisingly readable when compared to "modern" JavaScript-like languages. The site linked above shows a very good example of this.

58 points by cgarvis 5y ago

Please no... I've been unfortunate enough to witness first hand what +-5,0000,000 lines of Natural Adabas code transpiled to +-15,000,000 lines of Java code looks like, and it was not pretty.

chris_st 5y ago
This. Friend of mine worked at a company that did COBOL to Java compilation, with the intent of producing "maintainable" code, and he reported (after several years of work) that this just wasn't possible (for them).
chess_buster 5y ago
I would like to know more… 8-)
- philipswood 5y ago
  This is from hearsay, since I was only there a few weeks before getting out, so I only spent some time on the floor and looked at the code for a bit: It was a municipal management system that grew over time (decades). At some stage a government standards body raised the legacy risk inherent in the Natural Adabas codebase. Some (pretty impressive) 3rd party tool was used to transpile the codebase to a more "modern Java web application architecture". The code wasn't idiomatic Java and used some extension libraries to supply missing capabilities. For example I don't recall ever seeing any other Java system that uses continuations. I spent an entire day tracing one field from the front-end to the database. I documented the components, flows, logic and db structures and then asked one of the team leads to verify if I got it right. She confirmed that I did. I then asked what the code on question actually does, functionally. She replied something to the effect of "Good heavens, I don't know either - you'll need to speak to one of the functional guys and then spend some time with the Natural code from before the transpilation". She needed about 6 months to get a new Java dev to a level where they could do minor feature requests or bug fixes. Understandably her ability to retain developers was quite low - they tended to leave quickly after spending time with the system. Business didn't seem to get why the velocity for new features was so slow. They didn't have an architect, documentation was fragmentary. Previous modernisation initiatives had already become obsolete as well: IIRC the App server was Glassfish and front-end (web) components were using some JBoss widget library that was already deprecated at the time. Like I said, I left quickly.
HideousKojima 5y ago
I've had to port some old Visual Basic WinForms apps to C#, only a few hundred lines of code for each app, and even that was a huge pain in the butt. Transpiling anything of significant size and complexity will require a metric ton of cleanup and refactoring just to make sure it all works right and can be reasonably maintained by other developers.

sharklazer 5y ago

Then you could transpile COBOL into Elixir...

WJW 5y ago

You can transpile anything to anything, but computers will not be able to rewrite the code to match idiomatic style in the new language. Rather, (taking the example from the article) you get COBOL style in Elixir syntax and everyone is unhappy. Much better options are to maintain a COBOL team that continuously updates the program during its lifetime so that knowledge of how it works is never lost, or (if that is no longer possible) do periodic rewrites every two decades or so. If your first response to this is "but that would cost a fortune!", you are completely correct. The biggest illusion in software is that a "complete" program is now "done" and will need no more investment. Software is a machine for producing information, fundamentally not much different from a lathe or a textile loom. If your company depends on a piece of software to continue existing, it is now de facto a software company. Many institutions have not yet realized this and will run into existential problems within a few decades.

scns 5y ago
Several Clojure libraries would like to have a word with you ;) Disclaimer: Neither a fanboi nor user, just read that potential users thought those libs were abandoned, since they havent been updated in years.

restlessbytes 5y ago

> What if we could transpile COBOL into Elixir You've then successfully ported your code base from one language for which it's really difficult to find programmers to another language for which it's really difficult to to find programmers.

carlmr 5y ago
I guess your comment was in jest, but I can find plenty of developers for elixir that are willing and able to learn it in a month if I want to.
- rad_gruchalski 5y ago
  Do you think they’d be happy to maintain a transpiled COBOL code?
  - carlmr 5y ago
    No, of course not, I was just getting at this specific point that there are few COBOL and Elixir developers. Which, while true, has little to do with the talent pool you can draw from.
    - rad_gruchalski 5y ago
      Makes sense. I’ve done some fair share of Erlang myself some years ago.
- LeonenTheDK 5y ago
  My company (I'm not the hiring manager, just in the know) has been struggling to find any kind of programmer who either knows Elixir, or who is willing to learn. I'd love to help them along because the workload is getting rough. Are there any tips you can share about finding them? Where do you post ads, what's the process like, remote or in person? Anything would help. Thank you!
  - 5y ago

tyingq 5y ago

You will have solved the easiest part. Now get started on replicating JCL, VSAM, CICS, IMS, RACF, and the rest of the ecosystem that COBOL code depends on :)

acdha 5y ago
Back in the late 90s I had the bright idea of shipping our COBOL runtime as a browser plugin. This worked relatively well for a fraction of our customers since we had a transparent remote ISAM & RPC system the plugin could use (the idea being that the browser plugin meant you only had to update your Windows desktop clients with new versions of the runtime; they'd get the latest app on load) but the rest had a huge thicket of system-level dependencies which made that hard to consider, and that was for customers who'd already been able to migrate off of mini/mainframe systems to Unix. At this point in time, the mistake is to hear “COBOL” and think about a programming language rather than environments where they've struggled to manage technical debt and staffing issues for decades. It's not that COBOL developers can't produce good code but rather than places which can modernize effectively did so 3+ decades ago. If some place makes the news now because of a COBOL-based system, COBOL is a symptom of a management failure.
- tyingq 5y ago
  Ah, a cobol browser plugin? Cool. And yeah, environments. It's like porting JS to the mainframe, but not providing the POSIX facade to allow it to make files, schedule batch jobs, kill processes, connect to the network, store data in a database, access rights, auth, etc.
  - acdha 5y ago
    Yes – AcuCOBOL had a COBOL development system which was byte-coded like Java (the technical founder had actually overlapped with Gosling in undergrad, I believe) so we already had the capability to copy the compiled program onto most platforms (Most Unix variants, VMS, Win16 and Win32, OS/2, DOS, OS/400, etc.) and launch it with the native runtime. There was also some ability to transparently redirect I/O — you could have any CALL which didn't wasn't in the local compiled code do an RPC call to a remote server, and redirect some or all ISAM operations to either a remote server or (with another license) a SQL database. Once they had that infrastructure, it wasn't a huge amount of work to package the runtime as a plugin which was configured to enable the remote call & I/O options by default. Which is exactly restating your last point: having already done the hard 95% of the work, this part was straightforward.

scns 5y ago

Why should we? When we have this: http://www.coboloncogs.org http://www.coboloncogs.org Sorry, no https availlable.

cdumler 5y ago

There are plenty of ways to port out of COBOL, none will work. I once interviewed for a COBOL position. It was a typical large financial institution. It was a lead position that wanted a migration plan out and then would lead to a team for me. I have a lot of systems integration and information management knowledge. I have worked on planning multi-year projects and migrating out of large systems like this before. The interview went well, and afterwards they showed me around the place and what they were doing. I sat down again in the office with the hiring director, and I enquired about how long he has been with the company and what he has been working on. Turns out he had been hired in five years ago and had already attempted this once before without success. I knew without a doubt why they didn't have success, and it had nothing to do with COBOL. Financial companies are highly risk adverse. COBOL developers know this. COBOL developers know that if the shop isn't COBOL their job is at risk. So, COBOL developers will constantly introduce "what about this risk" issues, which then must be considered in committee; thus, the company is eternally paralyzed. The fact that the director couldn't make it anywhere in five years meant nothing was going to change. As I recall, I checked in a few years later and they were still in the same place. I suspect it might have been a decent place if all I wanted in life was a paycheck. They were nice people.

goto11 5y ago
Are these COBOL programs running on obsolete hardware, or are the systems virtualized these days? I suspect the way forward for COBOL is to modernize the development tools around it, rather then rewrite the code itself.
- rad_gruchalski 5y ago
  Have a look at Micro Focus compiling COBOL to .net and java. They’ve been doing this for minimum 11 years now.
- rovr138 5y ago
  Obsolete hardware? Mainframes are still a thing.
  - 5y ago

lucozade 5y ago

I feel a need to comment but I can't find a form of words that isn't condescending to the point of rudeness. So this will probably come off as rude... Transpiling, to more or less any language, is the easy bit. By a very, very long way. The hard bit is everything else. I mean, do they really think they're the first people to think about using a transpiler over the last 30/40/50 years? If they had said that they'd used their transpiler on a real production codebase and their transpiled code was now running in production in any volume, I'd be quite impressed. But they didn't say that because it's blatantly obvious from the tone of the article that that will never occur. Now, I don't have any issue with people being ignorant of a subject that they don't understand. That's the norm for most people for most things. But I have to say that this level of naivety doesn't reflect well on their company. They clearly made no effort to understand the problem that they are purporting to solve. Is that really how they function as a company?

Wildgoose 5y ago

The Japanese have a philosophy whereby they will rebuild a shrine every 20 years. The knowledge of what is necessary remains current, and understood. And the shrine continues in its purpose. Perhaps we should consider how we can regularly rewrite different parts of our software ecosystems using new languages and approaches while preserving the essential knowledge and security aspects of what we have already built? The important part isn't the language that the code is written in, it is the full understanding of the problem and thus the solution provided.

flohofwoe 5y ago
IMHO a more realistic idea is to treat the COBOL code as the "idea" or "essence" of the shrine which eternally remains the same, and only rebuild the "physical presence" of the shrine, which would be the environment the COBOL code runs in (e.g. modernize the hardware, the operating system, the debugging/development tools and virtual environment (== emulator) the COBOL code runs in, but don't rewrite the COBOL code itself).
- rowanG077 5y ago
  But then you have solved nothing...
  - flohofwoe 5y ago
    Maybe, but "nothing" is still much better than making things worse (first, a rewrite usually needs to be bug-by-bug compatible, so you have almost no leeway to "improve" the product, second, new code has new bugs that need to be found and fixed, don't underestimate the amount of work that has gone into a 50 years old code base that still does its job).
ehnto 5y ago
I don't think new languages and tools are necessary in all circumstances, I imagine part of the process of rebuilding every 20 years is to not forget how to build in the first place. Being around for the frontend engineering revolution taught me what it means for an industry to forget how to build, and have to re-learn many already hard learned lessons. But maybe I'm looking at it wrong, and it was that re-learning process that was the re-building after all? I don't know. All I do know is that you rarely get enough time in software to master your tools before everything changes, and you have to build the same old software requirements in brand new ways.

bencollier49 5y ago

The issue typically isn't just the COBOL itself, but the surrounding architecture. This will take in the nuances of the underlying operating system, system language operations and batch tasks. For example, the COBOL might potentially have been on an ICL VME system. This will undoubtedly have a lot of support code written in things like SCL (System Control Language), and potentially even 68k assembly. There are companies which specialise in migrating COBOL code from legacy environments. This can involve migrating the COBOL code itself to a different variant and rigorously testing it, and then often introducing utilities which replace operating system functionality which was present on the original mainframe. The alternative is to "salami slice" bits of functionality into modern services written afresh, and slowly work towards decommissioning the old setup, but often this has to be done at the same time as a migration to modern hardware, due to the scale of the systems involved and the time taken for these sorts of projects to complete.

imglorp 5y ago
Why would there be any 68k assembly floating around in this domain?

forgotpwd16 5y ago

No one running COBOL will use it because those legacy applications "just work". Debugging and making certain the resulted transpiled code does as well will take a monumental effort (read: money). That is why those codebases haven't been ported because, based on similar efforts, transpilers are only partially easier than a manual rewrite. That answering the what if question. The project itself is interesting.

pronoiac 5y ago

I checked my bookmarks, and there have been success stories for porting cobol into other languages. Here's a discussion from 2019, from cobol into Java: https://news.ycombinator.com/item?id=19839563 https://news.ycombinator.com/item?id=19839563 Phase 1: automation of cobol to (ugly) Java Phase 2: make the code more idiomatic for (cleaner) Java Phase 3: move the infrastructure to AWS In the discussion, someone mentioned "There are commercial COBOL compilers available that compile to Java bytecode." Offhand, if someone were still on cobol, I'm not sure if they'd trust the comparatively new Elixir, but I can also see leapfrogging being a thing. (And I know it's based on Erlang, which pre-dates Java.)

vajrabum 5y ago

Anybody who is developing a COBOL compiler should know that there's a test suite for the language. See here (https://www.itl.nist.gov/div897/ctg/cobol_form.htm https://www.itl.nist.gov/div897/ctg/cobol_form.htm) Also, I haven't seen any mention of any of the bits of the COBOL ecosystem here? No DB2, IDMS, IMS DB/DC, VSAM, CICS, REXX, JCL? These are a big part of why COBOL applications are sticky.

tjalfi 5y ago

This reminded me of the old lisp2cobol[0] joke script. [0] https://stuff.mit.edu/afs/sipb.mit.edu/project/lisp2cobol/l2c https://stuff.mit.edu/afs/sipb.mit.edu/project/lisp2cobol/l2...

rhabarba 5y ago

COBOL code is surprisingly readable when compared to "modern" JavaScript-like languages. The site linked above shows a very good example of this.