3 ms·

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

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.

xvilka 4y ago
Thanks for the answer. Looking forward for your project success!
Rochus 4y ago
> Otterkit compiles to C# 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.
- Semaphor 4y ago
  > Why not directly compile to CIL? 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_new_free_and_open_source_cobol_to_c/j3l5p68/ https://old.reddit.com/r/csharp/comments/1074jdj/otterkit_a_...
  - garganzol 4y ago
    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.
- KTSnowy 4y ago
  > 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#.
  - Rochus 4y ago
    > advantage of the dotnet compiler optimizations 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.
webdevver 4y ago
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. Mind you, I haven't actually tested it myself. Link: https://gcc.gnu.org/pipermail/gcc/2022-March/238408.html https://gcc.gnu.org/pipermail/gcc/2022-March/238408.html

xvilka 4y ago

Thanks for the answer. Looking forward for your project success!

Rochus 4y ago

> Otterkit compiles to C# 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.

Semaphor 4y ago
> Why not directly compile to CIL? 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_new_free_and_open_source_cobol_to_c/j3l5p68/ https://old.reddit.com/r/csharp/comments/1074jdj/otterkit_a_...
- garganzol 4y ago
  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.
KTSnowy 4y ago
> 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#.
- Rochus 4y ago
  > advantage of the dotnet compiler optimizations 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.

webdevver 4y ago

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. Mind you, I haven't actually tested it myself. Link: https://gcc.gnu.org/pipermail/gcc/2022-March/238408.html https://gcc.gnu.org/pipermail/gcc/2022-March/238408.html