What's your use case, here? What problems do you expect to solve for someone that chose to adopt this?
Are y'all scratching a very particular itch, and open-sourcing the outcome? Or is this more of an academic / POC thing, to see what it looks like to build a COBOL to dotnet transpiler?
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.
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.
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.
Is it really a transpiler? Why not directly compile to CIL?
> I'm sure that most people are not aware that COBOL has generics
But this is only in the more recent standards, isn't it? I guess that 95% of existing Cobol applications still use the 1974 standard version.
This was asked and answered on reddit [0]:
> 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.
[0]: https://old.reddit.com/r/csharp/comments/1074jdj/otterkit_a_...
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.
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.
Mind you, I haven't actually tested it myself.
Link: https://gcc.gnu.org/pipermail/gcc/2022-March/238408.html
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#.