Marvel Television has been on fire this past year with WandaVision, Falcon and the Winter Soldier, and most recently, Loki. Tomorrow, the next series called “What If?” premieres, and I am really looking forward to it. The show will explore what the Marvel Cinematic Universe (MCU) would look like if pivotal moments from throughout the MCU were different.
For example, the first episode explores what would happen if Peggy Carter had taken the Super Soldier Serum instead of Steve Rogers to become Captain America. These “what if” ideas are retrospective in nature, exploring “what would have happened if”. While interesting to consider, this type of thinking is less useful in the real world. In reality, future-oriented “what if” questions–that explore what possibilities might lay ahead–are far more impactful.
I’m happy to say the exploration of future-oriented “what if” questions is core to the Elixir programming community. We exist in large part due to one big “what if”: what if there was a new programming language that could use modern syntax, but still deliver the reliability of a 30-year old, rock-solid virtual machine?
Other “what ifs” followed:
- What if we built a blazing fast web framework in Elixir?;
- What if we put Elixir on embedded devices?;
- What if you could do Machine Learning on the GPU with Elixir?; and many more.
Along the way, there have also been plenty of “what ifs” that didn’t work out, such as “What if Elixir was Object Oriented?” or “What if Elixir had an explicit type system?”.
Today, I am sharing something I’ve been working on related to COBOL–all stemming from a “what if?” discussion that came up here at DockYard.
Like me just a few months ago, you may have heard about COBOL in your computer history class but have never seen or written a line of it. The Smithsonian Institute COBOL History page states:
Fifty years ago, each computer maker used its own programming languages to tell a computer what to do. In 1959, a group of programmers devised COBOL, a COmmon, Business-Oriented Language. Programs written in COBOL could run on more than one manufacturer’s computer. In a 1960 test, the same COBOL programs ran successfully on two computers built by different manufacturers.
But a language created in 1959 can’t possibly still be in use today, right? Wrong. According to Reuters:
- 43% of banking systems are built on COBOL;
- 80% of in-person transactions use COBOL;
- 95% of ATM swipes rely on COBOL code; and
- 220 billion lines of COBOL are in use today.
That same article notes:
An aging programming language known as COBOL underpins much of the U.S. financial industry, but it has fallen out of favor among coders. This sets up a problem when systems run into glitches or need updates, and companies no longer have COBOL experts on hand.
With a renewed focus on “infrastructure” in the recent political landscape, and the very real potential that these COBOL systems could be revisited, the question arose in a DockYard discussion: “What if we could transpile COBOL into Elixir?”
I have been looking for a larger Elixir project to start or support, so I figured, why not see what it would take? While I knew it was a long shot–and there are any number of ways it might fail–I thought it was worth a look. A few hours, an “all you need to know about COBOL” YouTube video, and a code spike later, and I hadn’t run into any complete roadblocks. Furthermore, what I remembered about the properties of the COBOL language that might lend themselves to this idea all seemed to be accurate.
Fast forward a few months to today. CobolToElixir has come a long way. It has support for many of the basic building blocks of COBOL and plans for tackling some of the larger language constructs. Most importantly, it has a framework for testing that will run COBOL code, convert the code to Elixir and run it, and then compare the two outputs to ensure they are the same. I have not yet run into any major roadblocks that I’ve been unable to work around, but there is still plenty to do that could uncover them.
The source code is available at https://github.com/TheFirstAvenger/cobol_to_elixir, and there is a Livebook that you can run to try it out for yourself. Below is an example basic COBOL program and what the transpiled Elixir code looks like:
COBOL:
>>SOURCE FORMAT FREE
IDENTIFICATION DIVISION.
PROGRAM-ID. Test1.
AUTHOR. Mike Binns.
DATE-WRITTEN. July 25th 2021
DATA DIVISION.
WORKING-STORAGE SECTION.
01 Name PIC X(4) VALUE "Mike".
PROCEDURE DIVISION.
DISPLAY "Hello " Name
STOP RUN.
Elixir:
defmodule ElixirFromCobol.Test1 do
@moduledoc """
author: Mike Binns
date written: July 25th 2021
"""
def main do
try do
do_main()
catch
:stop_run -> :stop_run
end
end
def do_main do
# pic: XXXX
var_Name = "Mike"
pics = %{"Name" => {:str, "XXXX", 4}}
IO.puts "Hello " <> var_Name
throw :stop_run
end
end
COBOL is different from Elixir in a number of ways. For example, above you can see that COBOL has a STOP RUN command which can happen anywhere in the code, completely ending the program. In the transpiled Elixir, we handle this with throw and catch. Additionally, all variables have a PIC (“Picture”) clause that defines the data type and shape. For example, the name variable above has a PIC of X(4), or XXXX, which means it is a string exactly four characters long.
Another difference, which has been addressed (though not shown in the above example), is the difference between COBOL group items and their near-counterpart in Elixir, Maps. One difference that hasn’t yet been addressed, but has a planned solution, is the immutability in Elixir vs. global variables in COBOL.
The goal of CobolToElixir is not to provide a one button accurate transpiling of a large codebase perfectly into Elixir. The idea would be that we transpile the code, test the accuracy with the built in tools, and possibly iterate on CobolToElixir to improve the transpiling of the specific codebase. Once CobolToElixir has done what it can, focus would move to iterating on the transpiled code to resolve differences in output and bring the code more in line with idiomatic Elixir. The CobolToElixir framework would be able to assist via the testing framework through this entire process.
If you are interested in following this project, star the repo and follow me on Twitter (@1stavenger). I would love input from anyone else who is interested in helping out on this project. Please reach out to me on the Elixir Slack channel (TheFirstAvenger).
And finally, what is your “What If?”. As mentioned above, the Elixir community is built on these “What If?” questions. If you don’t have one yet, keep thinking about it, and when one comes to you, pursue it.
Join the conversation and let us know what you think on Twitter and LinkedIn.
DockYard is a digital product consultancy specializing in user-centered web application design and development. Our collaborative team of product strategists help clients to better understand the people they serve. We use future-forward technology and design thinking to transform those insights into impactful, inclusive, and reliable web experiences. DockYard provides professional services in strategy, user experience, design, and full-stack engineering using Ember.js, React.js, Ruby, and Elixir. From idea to impact, we empower ambitious product teams to build for the future.
