KTSnowy

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.

"This is not your grandparents' COBOL"

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

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.

Yes, exactly. Specially when paired with dotnet NativeAOT when deploying to a serverless service, could save a bit on server costs.

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.

Sent you an email. Is there anything you want to discuss that can't be done here publicly?

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.

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.

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.

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)