Cobaul: A COBOL to WebAssembly Compiler | Hacker News Reader

Cobaul: A COBOL to WebAssembly Compiler

github.com

120 pointsrhabarba54 comments

I'm fascinated by the interest (outside of places where COBOL is used day-to-day) COBOL these days. I learned VAX COBOL at college in the 80's and was fairly proficient with it, and dabbled around with DG COBOL afterwards whilst in paid employment, but moved on to PC development (C, dBase, Clipper etc).

As an aside I feel they missed the chance at a better name: "CobWeb".

I move that the name be changed to CobWeb immediately.

Ohhhh! That’s great. I can maybe help make that happen.

Yes, we are renaming it. That's a great suggestion. So sad we didn't think of it.

Done: https://github.com/cloudflare/cobweb

Well that's a first for me, ever. Do I get a contributor mention for the new name ;)

Drop me an email (jgc @ cloudflare)

I feel like knowing some COBOL would be a handy thing considering how much of it is still hanging around. My main problem is that it's easy to find toy examples of doing some simple things, but all the value is in supporting massive, decrepit old codebases. I wish I could find a good example of that with some descriptions helping me unravel it, so I could take on a bit of COBOL work with confidence.

I love WASM and I love being able to wrap legacy work up so it can be called with modern systems (I did an AS/400 driver so a decades-old but still updated DB2 could be queried by a Drupal Commerce site), so this project is exciting. Just wish I could connect the obvious advantages I see in this project and other stuff like cloudflare's announcement with something full of pitfalls.

Careful, you might get what you ask for.

But I think learning Cobol is only about 25% -- the hard parts are knowing what the legacy codes does vs. what it's supposed to do vs. what you really want to do, understand how and when the Cobol code actually runs on the legacy system (JCLs, schedulers, etc.), understanding what arbitrary limitations you must carry over to your new system, etc. -- all of which is probably not documented very well.

This isn't the first time someone tried to bring COBOL to the web. 20 years ago, there was CobolScript[1] by a company called Deskware.

From an old article[2] about it:

> New language speaks up to help solve an old problem

> Catherine Mitseas

> Tampa software firm DeskWare Inc. (http://www.deskware.com) has launched a new language that Web-enables COBOL (Common Business-Oriented Language).

> Matthew Dean and Belmont, Calif.-based Charles Schereda, both engineers, started designing the new language while marketing their Y2K software products. As they worked with clients, such as the Tennessee Valley Authority, the two realized the need for businesses to leverage COBOL systems while ramping up to do work on the Internet.

> COBOL, a language designed in 1959 at the Conference of Data Systems Languages, is why Y2K fever has gone on for the last several years. Because programmers condensed dates down to two digits, computers interpret the year 2000 as 1900.

> According to Dean, there are 700,000 COBOL programmers in the United States, and many businesses still have key databases running in the old language. Because of Y2K, these companies have had to invest vast amounts capital in their systems, which run on COBOL. As a result they designed COBOL Script, which has been in Beta-testing for eight months.

> The new type of COBOL allows programmers to tie these existing COBOL-dependent business applications onto the Internet. Dean believes it will allow companies to use COBOL-trained employees and, with minimal amounts of retraining, Web-enable business applications without having to go to bleeding edge technology.

---

[1] https://en.wikipedia.org/wiki/CobolScript

[2] https://web.archive.org/web/20010305215620/http://tampabay.b...

Here’s hope that the WASM approach will not fall out of fashion that soon.

Cloudflare announced this in a blog post a few months ago (https://blog.cloudflare.com/cloudflare-workers-now-support-c...). They explain a bit more about the history of COBOL and why this specific project exists.

Oh, thank you. I had not seen that!

That was great fun to work on and I'm amused to see my COBOL implementation of Conway's Game of Life still running just fine on Cloudflare Workers.

We've announced a few more languages for Workers: https://blog.cloudflare.com/cloudflare-workers-announces-bro...

Still no Lua? :(

Can't you compile a Lua application into WASM and run it that way?

You can compile the Lua VM into wasm+JS and run it there, yes. (for example, https://daurnimator.github.io/lua.vm.js/lua.vm.js.html)

Pure wasm doesn't work yet since the VM needs either C++ exceptions or longjmp (to unwind). Wasm exceptions support will eventually help there, but meanwhile there is a dependency on JS exceptions.

You scientists were so preoccupied with whether or not you could, you didn't stop to think if you should!

What is dead may never die.

Perfect;

You mean, like COBOL jokes?

I learned COBOL, Fortran and RPG II. I managed to avoid doing much of COBOL or Fortran but spend a few years doing RPG II. Glad that is in my distant path!

And with strange aeons even death may die...

It should be the new slogan for Python 2.7

The best thing to happen to COBOL since COBOL ON COGS: http://www.coboloncogs.org/INDEX.HTM

How much do tools such as this one help with reuse or porting of real COBOL applications, as opposed to textbook examples?

As I understand it, many COBOL programs of current practical interest make extensive use of data management and transaction processing facilities that aren’t part of the COBOL language itself.

Can anyone share their experiences? For example, what fraction of the COBOL modules in a typical application would be able to be translated by a compiler that doesn’t handle statements such as “EXEC CICS” or “EXEC DLI”?

Don't forget to include 'EXEC SQL'. For IBM mainframe Cobol, how many progrmams DON'T depend on the mainframe environment specific features/services? Probably zero or close to it. I think the environment for other vendors (Microfocus, Accucobol) is a bit more forgiving, I don't have experience with them so can't say for sure.

Another, maybe more subtle mainframe pecularity is how it maps dataset (ie file names) names to 'dsnames' (Cobol source code construct) at runtime, tied together by JCL.

There's also lots of Adabase, IDMS, IMS, third party schedulers, and maybe some assembler sprinkled around. And lots of smaller problems like printing, EBCDIC centric code, record based files, etc.

I assume Microfocus provides solutions for some of this.

Microfocus did a thing where you could port COBOL TO .NET. I haven't worked with it myself but know Barclays used it to migrate a lot of COBOL in the mid 2000s.

The COBOL codebase I have seen I'd rather not have ported.

This has to be the biggest "jump cut" in the history of compilers!

ref: 2001 A Space Odyssey: (https://en.wikipedia.org/wiki/Interpretations_of_2001:_A_Spa...)

"Arthur C. Clarke, in the TV documentary 2001: The Making of a Myth, described the bone-to-satellite sequence in the film, saying "The bone goes up and turns into what is supposed to be an orbiting space bomb, a weapon in space. Well, that isn't made clear, we just assume it's some kind of space vehicle in a three-million-year jump cut"

I know recently with COVID states were looking for COBOL people to work on older systems like unemployment and others. Wonder if something like this could let them write a more modern system but just copy and paste some of the business logic and create a bindings between them maybe. That's the main use case I'd think something like this would bring.

Wouldn't surprise me if some banks with modern websites using React, etc are just talking to some custom made http proxy on commodity hardware talking to the older mainframes on the same network where the actual real business logic is done.

that's exactly how our world works. also, there are entire layers of mainframes

Does COBOL translate easily to more modern languages? Anything tricky or odd about it? I’ve never needed to use it.

COBOL is quite modern actually, nowadays it support OOP, modules, cloud deployments, JVM and .NET backends.

https://www.microfocus.com/en-us/products/visual-cobol/overv...

Latest revision is from 2014.

There's a screenshot with some source code up there. It's kind of refreshing to see function calls where the syntax for pass by reference and pass by value is literally "by reference" and "by value".

https://9b74456f2e4bcbc20970-51751c7e8fb38e7c8b474cab6c7dc60...

As an old-school (i.e. >25 yrs ago) COBOL programmer its pretty jaw dropping to see that the language has continued to evolve.

Modern COBOL would have a DDL which makes using JSON-like and XML-like nested data structures as easy as its existing DDL makes using record-oriented data structures.

Using COBOL is a joy, one should never NEED to use it.

YMMV. :-)

First day of intro to programming at my university and the professor was introducing himself and his background and how his first job was writing cobol at a Paper Mill. He said COBOL was a revelation at the time and that we would never need to learn or use it.

Enter stage left my first job as a developer in 2016 and I'm tasked with learning cobol to support customizations to their 25 year old Lawson Implementation.

I'll probably never use it again but reading and writing cobol code opened my eyes to different design patterns not often seen in more modern languages. Seeing clever implementations of features that come out of the box in modern languages was really neat.

That sounds super interesting. Can you describe some of the interesting design patterns/clever implementations you saw? I feel like there is a lot of benefit in looking at weird languages as it opens your mind to new ways of solving problems.

It’s pretty easy and straight forward. You run into more interesting issues working with it though.

I just got done (towel thrown) after a 12 hour workday where 30 minutes were code change, build, unit test and the rest was trying to get the tester, who is COBOL age appropriate, to understand how our program works, how we use APIs to communicate with other systems and how to test it.

In the end the Jira errand got sent back to me because of an error in an unrelated program that we verified existed earlier today before my code was deployed, because it ‘has to be the API program’. =,)

They’ve also apparently been testing all other APIs by sending simulated OK responses with the expected data <3

And remote pandemic work in a team where everyone is 2x my age has gotten me into a p. deep depression.

Old-style COBOL translates trivially to or from very brain-dead imperative style code with lots of goto.

If you can look past the syntax, modern COBOL is a decent enough compiled language, with most of the stuff you'd expect.

I can't look past the syntax.

What’s wrong with the syntax? It is essentially English with some minor rules attached.

Like with C family vs. ML family vs. APL vs. Pascal family debates, some people consider those sort of syntax differences to be deal-breakers. I personally try to keep an open mind.

I hope we can agree that APL does not fit the list here. It does not even have words!

(;-))

I've come to take, "If you can look past the syntax..." as a semantically void formulation that is only there because its presence is mandatory whenever you're making a statement about a language that doesn't look like C.

In general, I agree with you, but you could apply it in reverse: "C function pointer declarations can be useful, if you can look past the syntax."

If it's any consolation, COBOL isn't a very interesting language, nowadays, despite its syntax. I had to suffer it a couple of decades ago, and I would never wish it upon anyone.

And I'm untroubled by syntax; I'd happily use C-like languages, ML languages, Lisps, etc. COBOL just isn't a good or interesting language nowadays, if it ever was.

Old school COBOL is very wordy, and full of program sections and divisions of dubious value, half of them seemingly redundant (source: I've written some while working at a bank, a few decades ago).

It feels as if you were writing something like this:

   Program Name The Program.
   Author the_af
   Data section.
   Some numbers.
   X 1.
   Y 2.
   Actual code section.
   Program beginning.
   About to start.
   Let's do this.
   Add X and Y, Giving Z, Z Being the Addition of X and Y, but not of W nor V. U is right out. 
   Having Computed Z, Z Being The Addition of X and Y, Z is therefore the Result.
   Give Result.
   Program End.

Ok, this is a parody, but it's also what writing COBOL feels like -- or at least, what it used to be like. And somebody thought because these were "English words", that this would somehow enable less technically minded programmers accomplish their tasks.

But sometimes you just want to write:

    f(x, y) = x + y

> Old-style COBOL translates trivially to or from very brain-dead imperative style code with lots of goto.

Provided the target language supports "goto", and "fall through PERFORMs" :)

>If you can look past the syntax, modern COBOL is a decent enough compiled language, with most of the stuff you'd expect.

Probably < 1% of production Cobol uses any syntax newer than Cobol 85!

But why

Reply on news.ycombinator.com