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