4 ms·

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,

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.

deleted 4y ago
[deleted]
xvilka 4y ago
Why not improving Gnu COBOL[1] then? It has better support for the COBOL constructs and libraries already. [1] https://gnucobol.sourceforge.io/ https://gnucobol.sourceforge.io/
- KTSnowy 4y ago
  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
le-mark 4y ago
> 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#.
nix23 4y ago
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 ;)
the_af 4y ago
> 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.

deleted 4y ago

[deleted]

xvilka 4y ago

Why not improving Gnu COBOL[1] then? It has better support for the COBOL constructs and libraries already. [1] https://gnucobol.sourceforge.io/ https://gnucobol.sourceforge.io/

KTSnowy 4y ago
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

le-mark 4y ago

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

nix23 4y ago

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 ;)

the_af 4y ago

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