After ~11500 lines of handwritten recursive descent, we finally finished implementing the whole syntactic analysis stage of the parser, which means that Otterkit can now syntactically and structurally understand the full Standard COBOL 2023 grammar. We'll now start working on the semantic analysis stage so that we can get name resolution fully working.
Hi, I'm the lead developer of Otterkit, a new free and open source COBOL compiler.
We've been recently invited by the awesome .NET team to appear live on their Languages & Runtime Community Standup. We'll be talking about the project, showcase an example of COBOL generics, and talk about our plans for the future of the project (and more COBOL-related things if we have time).
We hope to help improve the COBOL ecosystem and help change the language's "outdated and not suitable for modern development" reputation, because it is much more capable and powerful than most people realize.
Modern COBOL with the 2023 standard is a very powerful and capable language that can do so much more than just legacy banking and financial systems.
With its OOP syntax which includes generics, auto-implemented properties, method overloading and type safety, together with its excellent error and exception handling, async messaging, and overall how reliable it is makes it a pretty awesome language for modern backends that need to be secure and stable.
I'm in my second or third project facing this very issue right now.
We run a lot of Java and C# and have migrated most things to various cloud solutions. But, we ofc still run some medium sized iron for all the COBOL. I doubt we'll migrate away from it since we have the devs, but for similar systems I think it could prove useful.
We'll all take a look at it later today! Fun with COBOL news that aren't paywalled =)
Let me know if your company needs any particular features from a third-party COBOL dialect. We could work together to implement compiler support for those and ensure it works with your codebase.
COBOL really needs more free and open source stuff, I'm hoping I can help.
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.
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.
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.
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.
I find COBOL to be a very interesting language, with a huge unexplored potential. For example, I'm sure that most people are not aware that COBOL has generics, method overloading, declarative error/exception handling, asynchronous messaging, etc.
This stuff is usually not taught by the current COBOL vendors. It's also very unfortunate that most compilers are closed source and quite expensive to use.
We're making a free and open source COBOL compiler to help improve the current state of the COBOL ecosystem. We hope that it will be production ready at some point.
> I find COBOL to be a very interesting language, with a huge unexplored potential. For example, I'm sure that most people are not aware that COBOL has generics, method overloading, declarative error/exception handling, asynchronous messaging, etc.
But most COBOL systems are legacy systems, using a version of COBOL designed many decades ago, and without any of these features.
Starting to use the features you list will effectively be like learning a completely new language, only without any of the upsides of modernity and all of the downsides. If you are going to migrate from legacy COBOL to slightly-less-legacy-COBOL-but-at-the-same-time-all-these-frightening-new-features, you might as well migrate to a more modern platform and language.
I know about GnuCOBOL, but both projects have different goals and ideals.
Otterkit compiles to C#, and GnuCOBOL compiles to C. The two are meant for different use cases. You wouldn't use a huge C program in a .NET backend, it would be a pain to make it work correctly and difficult to maintain.
GnuCOBOL also doesn't support quite a bit of COBOL's features. It only supports the procedural part of the language, and that is only a small part of it compared to the object oriented side of COBOL. Otterkit will support both, and the new 2022 standard.
> Exactly, there's no way that we could optimize the IL better than the dotnet compiler, so we chose to emit C# text and let the dotnet compiler do the optimization for us.
> This also makes it a lot simpler to generate code, without having to deal with the lower level IL.
JFYI, optimizations performed by C# compiler are not that great. They are present but their extent is pretty limited.
Actually I like it better when COBOL gets transpiled to C# and not IL but for another reason. COBOL -> C# pathway allows migration to something a bit more modern than COBOL itself. This may be crucial for some projects.
> Is it really a transpiler? Why not directly compile to CIL?
The end result of running Otterkit will be an executable or a C# DLL, so compiler would still be the most accurate word to describe it. If it stopped at the translation stage it would be a transpiler.
We're compiling to C# source text so that we can take advantage of the dotnet compiler optimizations. Otterkit calls the dotnet compiler after translating to C#.
That's mostly constant folding and a bit of peephole optimization; the CLI JIT or AOT compilers do most optimizations on the CIL level.
> so compiler would still be the most accurate word to describe it
Well, you do a source-to-source translation from Cobol to C#. The terminology is fuzzy, but usually we call it a transpiler if the output is yet another high-level programming language. But who cares.
If it is of any interest: In 2022, an announcement was posted to the GCC mailing list introducing a prototype implementation of a COBOL frontend to GCC, which would in theory compile COBOL directly to a target machine of choice.
> For example, I'm sure that most people are not aware that COBOL has generics, method overloading, declarative error/exception handling, asynchronous messaging, etc.
It is interesting, but the reality is the vast majority of cobol in the world is the 85 standard. And although the 2022 standard may have some nice features, the language is simply too verbose; similar to Visual Basic vs c#.
I think exactly like you, but about ADA, for a very long time compilers where closed-source, for crazy machines and additionally really expensive, the situation for ADA is now much better, but it lost it's momentum then, but regains a bit of it in the past years, especially because of the rust hype ;)
We're planning to make a COBOL <=> C# bridge library, which will allow you to call C# methods from COBOL. The idea will be to find a way to expose C# classes and methods using COBOL's existing syntax.
We still need to figure out the how to best approach this, without completely breaking standard compatibility and without introducing mixed C# and COBOL syntax (which would end up looking quite unpleasant in my opinion)
